On Tue, Sep 1, 2015 at 6:41 PM, Tim Peters <[email protected]> wrote:
> [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). > Ah, now I understand why someone in desperation proposed to do make some kind of assumption about the size of DST offsets. > 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 ;-) > OK, looks like the PEP has some evolving to do! -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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/
