[Datetime-SIG] Another round on error-checking

[Guido van Rossum]

On Tue, Sep 1, 2015 at 6:41 PM, Tim Peters <tim.peters at gmail.com> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150901/01df7a74/attachment.html>