[Datetime-SIG] Another round on error-checking

[Tim Peters]

[Guido]
> As a point of order, I don't have time today (nor probably this week) to
> keep up with this discussion. :-(

So. short & sweet, the higher-order bit of the hash problem is easy
enough to sketch.  Suppose x and y represent the earlier and later of
an ambiguous time in their common zone.  All fields are identical
except for `fold`.

If intrazone comparison ignores `fold`, then x == y is true.  Implying
their hashes must be equal.  Implying that (any
non-insanely-convoluted) hash() must also ignore `fold`, to get the
same UTC offset for both.  All fine so far.

But screws up when x and y are (for example) converted to their _real_
UTC equivalents, ux and uy.  Those _aren't_ equal.  hash(x) == hash(y)
== hash(ux) then, but hash(uy) is almost certainly different.  But y
== uy is true, so we're left with two equal datetimes whose hashes are
almost certainly different.  Note "y == uy is true" must be so for
backward compatibility (interzone comparisons have always been
supported).

The high-order bit of the proposed solution (to this,and to the loss
of total ordering, and ..) is to stop ignoring fold=1.  End of
problems.

Start of other problems.  For why the latter are thought (so far) to
be infinitely easier to live with, you would have to follow the
discussion.  By the time you do, there will be no problems left - or
at least none we'll admit to ;-)