[Datetime-SIG] Another approach to 495's glitches
tim.peters at gmail.com
Sun Sep 6 20:58:56 CEST 2015
> Consider two aware datetimes that compare equal. The task is to prove
> they have the same hash. The subtlety is that while __eq__ and
> __hash__ both use a notion of "UTC equivalent", they're not always the
> same notion. __eq__ always uses the given values of `fold`, while
> __hash__ always forces fold=0.
Which obviously ;-) suggests yet another, possibly cleaner, approach:
have interzone subtraction, and all interzone comparisons, _also_
force fold to 0 (instead of having only interzone __eq__ and __ne__
special-case fold=1) . There are many details about consequences for
me to work out, but it sounds promising on the face of it.
"The story" gets a lot more uniform then: fold=1 is simply ignored
(acts as if 0) by virtually everything, except for 495 tzinfo
operations, where `fold` is essential.
Then we'd again have, e.g.,
uearly == early == late != ulate
uearly < ulate
but "late != ulate" in this variant not because __ne__ is special
casing fold=1, but because all cross-zone comparisons use the
force-fold-to-0 UTC equivalents for both `late` and `ulate`, and
they're simply not equal (assuming 495-conforming tzinfo; for a
pre-495 tzinfo, they would be equal, but in that case uearly==ulate
We'd also have
late - ulate != timedelta(0)
for the same reason, and consistency between interzone comparison and
subtraction would be restored.
Trichotomy for cross-zone comparison would also be restored (for x and
y in different zones, exactly one of x<y, x==y, and x>y would be
That zone conversion isn't always order-preserving would remain so,
but it's impossible for any scheme to always preserve order so long as
early == late
in the source zone, and it's highly desirable that they do compare equal.
The only remaining obvious glitch is that Interzone by-magic
subtraction and comparison would act as if fold=0 all the time, so may
return wrong results in cases where fold=1, although wrong results
consistent between interzone subtraction and comparison.
I don't care much, for reasons explained before. Convert to UTC first
if you need to care about cross-zone comparison or subtraction in
cases of ambiguous times - that will always get the right answers
(assuming 495-conforming tzinfos are in use).
More information about the Datetime-SIG