[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. _______________________________________________ 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/
