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

[Tim Peters]

[Tim]
>> Because all versions of Python expect a very specific pickle layout
>> for _every_ kind of pickled object (including datetimes)..  Make any
>> change to the pickle format of any object, and older Pythons will
>> simply blow up (raise an exception) when trying to load the new pickle
>> - or do something insane with the pickle bits.  It's impossible for
>> older Pythons to know anything about what "the new bits" are supposed
>> to mean, and there is no way to spell, in the pickle engine, "but if
>> you're an older version, skip over the next N bytes".

[Random832 <random832 at fastmail.com>]
> Well, you could have put some reserved bits in the original pickle
> format for datetime back when it was first defined, or even just allowed
> passing in a longer string for future extension purposes.

Yes, we "could have" done that for all pickle formats for all types.
But why on Earth would we?  Pickle size is important to many apps
(e.g., Zope applications can store billions of pickles in databases.
and it may not be purely coincidence ;-) that Zope Corp paid for
datetime development), and there would have been loud screaming about
any "wasted" bytes.


> 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.


>> It's not so much a "good idea" as that it's the only idea consistent
>> with Python's "naive time" model.  Folds and gaps don't exist in naive
>> time.  Indeed, the _concept_ of "time zone" doesn't really exist in
>> naive time.  There's _inherent_ tension between the naive time model
>> and the way multi-offset time zones actually behave.  So it goes.

> But why does it need to be consistent? You can't compare naive datetimes
> with aware ones. If you want to sort/bisect a list of datetimes, they
> have to either all be naive or all be aware. So when we're talking about
> how ordering works, we're fundamentally talking about how it works for
> aware datetimes.

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.

Apps that can't tolerate naive time should convert to UTC first.  End
of problems.