[nylug-talk] Python time zones

[Chris Knadle]

On Wednesday 05 March 2008, Peter C. Norton wrote:
> >    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).

   In this case the problem relates to flight schedules, so neither the start 
nor stop time is current clock time, if that matters.

> 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.

   Last I spoke to the programmer, he was having problems with several cases 
relating to DST.  DateTime + TimeDelta landing during a DST switchover is 
possibly another case, since I believe a time delta is not TZ aware.

   My only involvement was helping him try to decipher some of the Python C 
source (datetime.c specifically, IIRC) which contains some cryptic 
documentation that reads like a mathematical proof.

   Since you seem interested, if I get a chance to talk to the him again in 
maybe a week or so I'll pass along what issues he's running into + relevant 
details.



On Wednesday 05 March 2008, Peter C. Norton wrote:
> On Wed, Mar 05, 2008 at 05:29:51PM -0500, H. G. wrote:
> > Is it too naive to convert to the Unix Epoch time, do the arithmetic,
> > then convert back?

   Depending on the circumstances that would probably be fine, especially 
since by default I believe Unix Epoch time is in UTC (though off the top of 
my head I'm not positive that's the case 100% of the time).

> Depending on the situation, this can be the wrong thing. A unix
> timestamp/epoch time does run out. So if you want to calculate a
> 30-year mortgage in 2009 on a 32-bit system, you definetely want
> something that will make sure that time_t won't wrap in 2038.

   Using Unix Epoch time also has another small quirk: in a script I wrote 
recently to parse bandwidth data from the bwm-ng package converts back to 
normal time, and I noticed that the time that comes back is slightly off -- 
because I think leap seconds aren't taken into account.  Was done with:

    D_TIME=$(date -d "1970-01-01 $TIMESTAMP sec GMT" "+%T")


   -- Chris

-- 

Chris Knadle
Chris.Knadle at coredump.us