[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 ;-) _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
