Gary Poster wrote:

> On Sep 6, 2005, at 3:39 PM, Fred Drake wrote:

>> This also brings up a question:  How should we deal with timezones for
>> historic dates?  The specific set of rules that apply to a given date
>> or datetime value have to be determined based on both the date and the
>> timezone indicator (abbreviation or name), applying the new US rules
>> for dates in the past is wrong.  Is pytz prepared for this, or do we
>> need to figure out how we want to deal with it still?  (I do hope all
>> the relevant information is in the timezone database, or we'll have to
>> think about supporting multiple versions of the database
>> simultaneously.)
> I can answer part of this, at least.  The Olson database has *very* 
> detailed about when to apply what time zone, and a cursory glance at  it
> seems to indicate that the particular new change is right.  I also  know
> pytz works hard to reconcile the very rich Olson data with the  datetime
> approach (see Stuart's email
> zope3-dev/2005-August/015222.html).
> This may be a bit complicated.  I hope Stuart--or Stephan--can shed 
> some light on the problem.

It handles historical and future timezone changes as well as can be done,
and I stuffed tests in that demonstrate this (probably where they don't
belong, but they are there).

There is an issue if timezone definitions change. So for instance, if you
pickled a datetime instance for 13:00 1st April 2007 US/Eastern with version
2005k of pytz, if you unpickled it using version 2005m of pytz it would
still think it was 13:00 1st April 2007 EST. If you then converted it to UTC
and back to US/Eastern (such as done by pytz's normalize() method), you
would end up with 14:00 1st April 2007 EDT. This is correct or crap
depending on what sort of applications you write :)

Stuart Bishop <[EMAIL PROTECTED]>

Attachment: signature.asc
Description: OpenPGP digital signature

Zope3-dev mailing list

Reply via email to