On 09/12/2015 12:23 PM, Random832 wrote: > I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. The tzlocal module, on the other hand, appears to > simply defer to pytz on Unix systems. > > My question is, _are_ there any correct reference implementations that > demonstrate the proper behavior in the presence of a timezone that has > daylight saving time transitions?
Well, the problem is that because datetime doesn't include any way to disambiguate ambiguous times, it's not really possible to implement complex timezones in a way that is both correct (if your definition of correct includes "timezone conversions are lossless") and also matches the intended model of datetime. I believe that dateutil.tz has a tzinfo implementation (though I haven't used it myself) which is zoneinfo-based and matches the intended model of datetime (in that "Eastern" is always the same tzinfo object, and all operations within "Eastern" are always done on a local-clock-time basis). But in order to do this it has to sacrifice round-trippable conversions during a DST fold (because it has no way to disambiguate between the first and second 1:30am in local time during a DST fold). Pytz makes the other choice, making all operations consistent and loss-less by using only fixed-offset tzinfo instances. The cost of this choice is the need to "normalize" after arithmetic, because you may end up with e.g. an EDT datetime during a timeframe when DST is not in effect and it should be EST instead. PEP 495 is intended to solve the "no way to disambiguate ambiguous local times other than using fixed-offset tzinfos" problem, which would make it possible to implement tzinfo classes following the dateutil model while still having loss-less conversions. Carl
signature.asc
Description: OpenPGP digital signature
-- https://mail.python.org/mailman/listinfo/python-list
