[Python-Dev] Status on PEP-431 Timezones

Stuart Bishop stuart at stuartbishop.net
Wed Apr 15 21:23:51 CEST 2015


On 15 April 2015 at 17:00, Lennart Regebro <regebro at gmail.com> wrote:
> OK, so I just had a realization.
>
> Because we want some internal flag to tell if the datetime is in DST
> or not, the datetime pickle format will change. And the datetime
> pickle format changing is the biggest reason I had against changing
> the internal representation to UTC.
>
> So because of this, perhaps we actually *should* change the internal
> representation to UTC, because that makes the issues I'm fighting with
> now so much simpler. (I'm currently trying to get arithmetic to do the
> right thing in all cases, which is crazy complicated).

Huh. I didn't think you would need to change any arithmetic (but
haven't looked at this for quite some time). You can already add or
subtract timedeltas to timezone aware datetime instances. The problem
with the existing implementation is the tzinfo instance does not have
enough information to do correct conversions when the time is
ambiguous, so it has to guess. With the addition of the is_dst hint to
the datetime instance, it will no longer need to guess.  Arithmetic
remains 'add the timedelta to the naive datetime, and then punt it to
the tzinfo to make any necessary adjustments' and I thought this would
not need to be changed at all.


> We can add support to unpickle previous datetimes, but we won't be
> able to add forwards compatibility, meaning that pickles saved in
> Python 3.5 will not be unpicklable in Python 3.4.

I don't think this can be avoided entirely. Any ideas I can come up
with that might help are worse than requiring devs to convert their
datetimes to strings in the rare case they need their 3.5 pickles read
with 3.4.


-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/


More information about the Python-Dev mailing list