[Tim]

...

[...] At this point we have:

u1 == dt1 == dt2 == u2 and u1 < u2 hash(dt1) == hash(dt2) == hash(u1)

(Parenthetically, note that despite the chain of equalities in the first of those lines, we do _not_ have u1 == u2 - transitivity fails, which is a bit of a wart by itself.)

[Ethan Furman <ethan@stoneleaf.us>]

At this point are there any other cases in the stdlib where transitivity fails?

I don't know. Python grew more features than I needed some time ago, so I'm not up to date. Did we ever implement the long-awaited RockScissorsPaper type? ;-) If not, there are none that I know of.

I was under the impression that such cases are to be considered bugs. I know it was a driving concern in the implementation of the enum module.

Sorry, I just had to laugh at the notion that enums _could_ be implemented in such a convoluted way that there'd ever be the slightest possibility of transitivity failing ;-) Anyway, sure, they're considered bugs, unless there's some darned good reason for it. In this case, I'm not entirely sure. Having comparison ignore `fold` seems aimed at backward compatibility - but it's another case where a non-zero fold can't appear unless a user forces it to, until 495-compliant tzinfos appear (in which case .fromutc() may create fold=1 by magic). When that happens, it will seem strange that fold is ignored by comparisons. At a higher level, I'd say that a datetime with fold=1 is veritably _screaming_ "I'm no longer following the naive time model". But there are consequences too from following that intuition ...