> 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.
You were told (by me) that its implementation of tzinfos was not the _intended_ way. Which is another way of saying it was an unanticipated way. "Correctly" is a whole different kind of judgment. pytz users who faithfully follow the docs seem happy with it. > 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? Which specific "proper behaviors"? :"Hybrid" tzinfos following the recommendations in the Python docs, including the sample implementations in the docs, correctly mimic local clock behavior (skipping the clock ahead when DST starts, and moving the clock back when DST ends) when converting from UTC. It's impossible now to do local -> UTC conversions correctly in all cases, because it's impossible now to know which UTC time was intended for a local time in a fold. For the same reason, it's impossible now to know whether a local time in a fold is intended to be viewed as being in daylight time or standard time. But do note limitations of the default .fromutc() implementation: it only guarantees correct mimic-the-local-clock behavior when total-offset transitions are solely due to a notion of "daylight time" that strictly alternates between .dst() returning zero and non-zero values. Transitions due to any other reason may or may not be reflected in .fromutc()'s treatment of the local clock. Most importantly, a transition due to a zone changing its base ("standard") UTC offset is a possibility the default .fromutc() knows nothing about. The wrapping of the IANA ("Olson") zoneinfo database in dateutil uses hybrid tzinfos (the intended way of wrapping zones with multiple UTC offsets), and inherits the default .fromutc(), so all the above applies to it. Including all behaviors stemming from the impossibility of disambiguating local times in a fold. That's not a bug in dateutil. It's a gap in datetime's design, It was an intentional gap at the time, but that pytz went to such heroic lengths to fill it suggests PEP 495 may well be overdue ;-) -- https://mail.python.org/mailman/listinfo/python-list