[nylug-talk] Python time zones

[Chris Knadle]

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.
   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?  ;-)

   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

-- 

Chris Knadle
Chris.Knadle at coredump.us