[nylug-talk] Python time zones

Peter C. Norton spacey-nylug at lenin.net
Wed Mar 5 14:27:47 EST 2008


On Wed, Mar 05, 2008 at 11:54:15AM -0500, Chris Knadle wrote:
> On Tuesday 04 March 2008, Ron Guerin wrote:
> > -------- Original Message --------
> > Subject: Re: [nylug-workshop] [Reminder] Regular meetings of the Python
> > workshop @ Tue Mar 4 6pm - 8pm (nylug-workshop at nylug.org)
> > Date: Mon, 3 Mar 2008 20:40:53 -0800
> > From: Peter C. Norton <spacey-nylug-workshop at lenin.net>
> >
> > Let's talk about time and time zones. There are interesting guidelines
> > and limitations on time (is anyone up on their relativity?) and the
> > oddities of timezones. Again, this is something I've played with a
> > little bit recently, and it turned out to be more interesting than I
> > thought it would be.
> >
> > Anyone who wants to see how difficult it can be, never mind American
> > and Australian DST, check out islamic time:
> 
>    Just something I wanted to mention concerning Python time zones since the 
> subject was brought up.  A friend has run into some interesting difficulties 
> dealing with timezones in Python relating to DST: the standard way Python 
> subtracts time is to check if the timezones match, and if they don't time is 
> converted to UTC first then subtracted, but if the timezones do match then 
> the subtraction is done directly.  [Seemingly makes sense at first.]  This 
> has an interesting consequence, though, because it means a change to DST 
> isn't taken into account -- because a switch to DST is only taken into 
> account during a conversion to UTC.

The tz object in a datetime object has the offset from UTC encoded in
it, so if the objects were created timezone-aware, they shouldn't
compare as being equal. I think there's a subtlety to this
that hasn't come out in the story.

>    There is likewise another problem concerning changing to DST.  Say for 
> instance that a calculated time lands within the DST period in the fall, at 
> 1:30am.  Well, which 1:30am is it?  The one *before* moving the clock back an 
> hour, or the one *after* moving the clock back an hour?  ;-)

That's a question you can answer in two ways: first, with the
timestamp, since the 1:30am before the DST switch will still be 60
seconds less than the 1:30am after the DST switch (but if you don't
have that info, you're in trouble). Also, with the proper timezone
info, 1:30am will be either standard time (EST, GMT-05:00) or daylight
time (EDT, GMT-04:00) so it's unambiguous once you have an unambiguous
format.
 
>    So even when you know the proper DST for a timezone, there are still some 
> interesting niche issues to figure out how to handle.
> 
>    -- Chris

Too true.

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.



More information about the nylug-talk mailing list