[nylug-talk] Python time zones

[H. G.]

On Wed, Mar 5, 2008 at 2:27 PM, Peter C. Norton <spacey-nylug at lenin.net>
wrote:

> 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.
>
>
> _____________________________________________________________________________
> Hire expert Linux talent by posting jobs here :: http://jobs.nylug.org
> The nylug-talk mailing list is at nylug-talk at nylug.org
> The list archive is at http://nylug.org/pipermail/nylug-talk
> To subscribe or unsubscribe: http://nylug.org/mailman/listinfo/nylug-talk
>


Is it too naive to convert to the Unix Epoch time, do the arithmetic, then
convert back?