[Datetime-SIG] Another round on error-checking
tim.peters at gmail.com
Thu Sep 3 17:30:12 CEST 2015
>> 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.
> 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.
More information about the Datetime-SIG