[Datetime-SIG] Another round on error-checking

[Alexander Belopolsky]

On Tue, Sep 1, 2015 at 12:12 PM, Guido van Rossum <guido at python.org> wrote:

> I could not accept a PEP that leads to different datetime being considered
> == but having a different hash (*unless* due to a buggy tzinfo subclass
> implementation -- however no historical timezone data should ever depend on
> such a bug).
>

I agree, but my analysis demonstrates that we cannot fix hash to make an
arbitrary tzinfo work.  ("Arbitrary" includes tzinfos with leap
microseconds and leap centuries.)   We can probably come up with a good
enough hash if we restrict fold sizes to multiples of 15 min up to 1 hour
and locations to a hour boundaries.

My preferred solution would be to delegate hash calculation to tzinfo and
make it someone else's headache, but I know you don't like this solution.



> I'm much less concerned about < being intransitive in edge cases. I also
> don't particularly care about == following from the difference being zero.
>

I believe Tim does care about this.  I did consider divorcing comparison
and arithmetic, but I think that led to problems with the total ordering.
Maybe we can make == differentiate between fold=0 and fold=1 at the expense
of not(a > b) and not(b<a) implying a==b?
I am not too hopeful.  Messing with total ordering axioms is just as fatal
for binary searches as messing with hash invariants is for dictionary
lookups.


> Still, unless we're constrained by backward compatibility, I would rather
> not add equivalence between *any* two datetimes whose tzinfo is not the
> same object -- even if we can infer that they both must refer to the same
> instant.
>

Not even for fixed offset timezones?  I am afraid this will break too many
programs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150901/cb246b7a/attachment-0001.html>