Fred Drake wrote:
> On 9/7/05, Stuart Bishop <[EMAIL PROTECTED]> wrote:
>>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 :) 
> This suggests to me that timezones should always go through a name
> lookup when unpickling.  That doesn't avoid all problems (e.g., use a
> timezone database that doesn't handle a future rule, convert an
> affected date to UTC, update to a new version of the database, and
> convert back to the original timezone), but there's a limit to what
> can be done.
> If timezones are always pickled as name references, that would avoid
> freezing broken rules into the database, at least.

They are picked as name references, and pytz tries a number of steps to get
the best match if the database has been corrected violently. You can't get
broken broken pickles unless I stuff up and remove a zone completely, which
would be a bug.

(see unpickler() in src/pytz/

I'm just describing what happens to pickled times when a politician waves
his hand and timezone information changes. There are two possible answers,
depending on if you think 13:00 should stay 13:00 no matter what timezone
changes happen, or if you think it should be corrected so the absolute time
it represents stays constant.

Stuart Bishop <[EMAIL PROTECTED]>

Attachment: signature.asc
Description: OpenPGP digital signature

Zope3-dev mailing list

Reply via email to