[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