[Datetime-SIG] Are there any "correct" implementations of tzinfo?

Tim Peters tim.peters at gmail.com
Tue Sep 15 00:09:47 CEST 2015

[Random832 <random832 at fastmail.com>]
> Would allowing a 16-byte string in the future have increased the storage
> occupied by a 10-byte string today? Would allowing a third argument in
> the future have increased the storage occupied by two arguments today?
> As far as I can tell the pickle format for non-primitive types isn't
> _that_ fixed-width.

Sorry, I'm not arguing about this any more.  Pickle doesn't work at
all at the level of "count of bytes followed by a string".  If you
want to make a pickle argument that makes sense, I'm afraid you'll
need to become familiar with how pickle works first.  This is not the
place for a pickle tutorial.

Start by learning what a datetime pickle actually is.
pickletools.dis() will be very helpful.

>>> That you didn't makes me wonder just where you're finding the space to put the
>>> fold bit.

>> PEP 495 gives all the details.  Short course:  there are bits that are
>> _always_ 0 now within some datetime pickle bytes.  `fold` will abuse
>> one of those always-0-now pickle bits.

> And what happens to older implementations if that bit is 1?

Unpickling will raise an exception, complaining that the minute value
is out of range.

>> Aware datetimes _within_ a zone also follow the naive time model.
>> It's unfortunate that they're nevertheless called "aware" datetimes.
>> So, sorry, even when sorting a list of aware datetimes, if they share
>> a common zone it is wholly intended that they all work in naive time.

> And if some of them share a common zone, then some of them will work in
> naive time, and some of them will work in aware time, and some pairs
> (well, triples) of them will cause problems for sort/bisect algorithms.

All sorts of things may happen, yes.  As I said, if you need to care,
convert to UTC first.  Most apps do nothing like this.

> Maybe it'd be best to simply ban interzone comparisons.

We cannot.  Backward compatibility.  If would have been better had
interzone comparisons and subtraction not been supported from the
start.  Too late to change that.

> Or have some sort of context manager to determine how arithmetic and comparisons
> work.

Write a PEP ;-)

More information about the Python-list mailing list