[Datetime-SIG] Timeline arithmetic?

[Tim Peters]

[Guido]
>> OK. I'll just remember "model A bad, model B good." :-)

[Carl]
> Fine by me. :-)

That's the spirit!  We'll have you chugging Dutch Kool-Aid yet ;-)


>> Or, perhaps more fairly, "model A is how pytz thinks, model B is how the
>> stdlib thinks."

> We'd be in better shape if it were that simple. pytz is strictly model
> A. Unfortunately the stdlib isn't consistent in how it thinks (short
> version: because __hash__ and cross-timezone equality and arithmetic
> implicitly treat aware datetimes as if they were unambiguous model A
> instants, when they aren't), and that's the root of all the difficulty
> with PEP 495.
>
> (I can give a longer explanation of _why_ that causes difficulty with
> PEP 495 if you want it, or you can go back and read the last few threads
> in detail, or you can just wait for the PEP :-) ).

Time for just the "high-order bits" again (for Guido):

Last time we left off with "End of problems.  Start of new problems.".

You can just repeat that now.  The new problems turned out to be even
uglier than the earlier problems.

So after going from "ignore fold as much as possible" to "pay
attention to it as much as possible", we're back to "ignore it as much
as possible" again.

The real pain remaining is that we'd love to ignore it in interzone
by-magic subtraction and comparison too, but doing so would break a
weak form of backward compatibility:  interzone code that already
works fine would continue to work fine, but after `fold` started
showing up may well no longer compute the _intended_ results in fold=1
cases.  Alex made a good case for why such code may actually exist,
and for why this would be a real regression for such code's intended
purposes.

So the best idea now is to special-case the snot out of fold==1 only
in interzone __eq__ and __ne__, to say that any datetime with fold=1
is "not equal" to any datetime in any other zone.  That hackery is to
squash the return of "the hash problem" (without needing an insanely
delicate hash() implementation).

This causes annoying special-case warts in current by-magic interzone
operations.  For example, cross-zone comparison trichotomy could fail:
 if x.fold==1 and y is in a different zone, none of x<y, x==y or x>y
would be true.

Best guess is that's of little consequence, but it's ugly.

So, if your time machine is gassed up and ready to go, just remove
by-magic interzone comparison and subtraction before they were added.
Thanks!  PEP 495 could be a delight then :-)