On Thu, Sep 3, 2015 at 6:59 AM, Carl Meyer <[email protected]> wrote: > But then it can't quite > decide how to rationalize that new bit of information with its naive > internal view of time, so it settles on a mish-mash of inconsistent > behavior that violates basic arithmetic identities we all learned in > elementary school and only makes any sense if you've followed this > entire thread. >
It is actually easier to understand if you *don't* read this thread because some of the earlier posts (including my own) are quite confusing. The rule we settled on is quite simple and consistent with the status quo. First, you need to realize that aware fold=1 times *can* be represented in the current version of datetime, but you must use a different tzinfo for that. Popular choices are timezone.utc or the fictitious fixed offset standard time zone. (I call these zones fictitious because they represent a possibly non-existing time zone which does not observe DST changes.) For example, in US/Eastern, if you want to represent [01:30/fold=1], you can either use [01:30/tzinfo=EST] or [06:30/tzinfo=UTC] which conveniently compare as equal. What 495 gives you is the third way to spell the same time: [01:30/fold=1,tzinfo=Eastern]. It is quite natural that this third spelling will have exactly the same properties as the first two: [01:30/fold=0] < [01:59/fold=0] < [06:30/tzinfo=UTC] == [01:30/tzinfo=EST] == [01:30/fold=1] < [02:00/fold=0] 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.
_______________________________________________ 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/
