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/tzinfo.py) 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]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
