[Datetime-SIG] Another approach to 495's glitches

[Tim Peters]

[Tim]
> ...
> 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
too).

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

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