[Datetime-SIG] Another round on error-checking

[Tim Peters]

[Alex]
>> The only "basic arithmetic identities" that are being violated here are
>> the ones that are already violated by aware datetimes.  For example (t1
>> - u) - (t2 - u) is not equal to t1 - t2 if u is a tzinfo=UTC instance
>> and t1 and t2 are two tzinfo=Eastern instances on the different sides of
>> the gap.

[Carl]
> Yes, you can already get such results, because aware datetimes are
> already sometimes aware and sometimes naive depending on context. That's
> a problem for learning the API, but it's at least an easily-explained
> problem: arithmetic within a timezone is always naive, arithmetic
> between timezones is always aware, if you mix the two (as your example
> does) you may get surprising results.
>
> I don't see any such easily comprehensible explanation for the new
> proposed PEP 495 behavior.

It can't possibly require more confusing words than _already_ exist
trying to explain the subtleties behind why timezone conversion can
fail in rare cases ;-)  People _expect_ the obvious roundtrip
identities there too.  It's a tradeoff.

The doc problem here seems much simpler:  in arithmetic involving two
datetimes, the operands will be treated as having distinct tzinfos if
at least one has fold=1.  It reduces to a prior case.  The equally
rare conversion problems require paragraph after paragraph to explain.

> ..
> Currently you only get results that violate arithmetic identities if you
> mix arithmetic within a timezone and arithmetic between timezones.

And we currently have timeline conversions that can violate basic
identities in _that_ space.  It is trading one for the other.