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

Tim Peters tim.peters at gmail.com
Mon Sep 14 22:15:35 CEST 2015


[Random832 <random832 at fastmail.com>]

Whether or not datetimes stored  tm_gmtoff and tm_zone workalikes has
no effect on semantics I can see.  If, in your view, they're purely an
optimization, they're just a distraction for now.  If you're proposing
to add them _instead_ of adding `fold`, no, that can't work, for the
pickle compatibility reasons already explained.  Whether something is
in a fold needs to preserved across pickling, but "almost all" pickles
need to be readable by older Pythons too.  This is doable adding one
bit, but not doable at all if we need to add arbitrary timedelta and
string objects _instead_ of that bit.

...

>>>  (No, I don't *care* how that's not how it's defined,

>> ?  How what is defined?:

> Just trying, unsuccessfully apparently, to head off the "no, it's
> defined as working the same as a naive datetime if the tzinfo values are
> the same" argument that got brought up the *last* time I made this
> claim.

Sorry, I still don't know what this is about.


>>> it is *in fact* true for the UTC value that you will ever actually get
>>> from converting the values to UTC *today*, and it's the only total
>>> ordering that actually makes any sense)

>> Well, you lost me there.  In a post-495 world, conversion to UTC will
>> work correctly in all cases.  It cannot today.;

> It'll provide *a* value in all cases.

It will provide the correct UTC offset in all cases.


> The sort order today is equivalent to using that value in all
> cases unless you've got a pathological tzinfo
> specifically crafted to break it. I think that's an important enough
> invariant to be worth keeping, since it is the only possible way to
> provide a total order in the presence of interzone comparisons.

Show some code?  I don't know what you're talking about.

It is true that the earlier and later of an ambiguous time in a fold
will compare equal in their own zone, but compare not equal after
conversion to UTC (or to any other zone in which they're not in one of
the latter zone's folds).  Is that what you're talking about?


More information about the Datetime-SIG mailing list