[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.
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 is no longer true that "arithmetic within a timezone is always naive." Now "arithmetic within a timezone is naive, unless you happen to have a particular kind of special time in a single hour once per year, in which case some kinds of arithmetic (dt/dt) are aware of the DST transition, but other kinds (dt/delta) still ignore it." Is that roughly what you propose to put in the documentation? Currently you only get results that violate arithmetic identities if you mix arithmetic within a timezone and arithmetic between timezones. Again, a simple rule. Under PEP 495, you can get such results even if you always stay within a single timezone. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
