On Sat, Sep 12, 2015 at 3:41 PM, Tim Peters <tim.pet...@gmail.com> wrote:
> > If there are not, maybe the intended semantics should go > > by the wayside and be replaced by what pytz does. > > Changing anything about default arithmetic behavior is not a > possibility. This has been beaten to death multiple times on this > mailing list already, and I'm not volunteering for another round of it > ;-) Tim and Guido only grudgingly accept it, but datetime already gives you "the pytz way" and PEP 495 makes a small improvement to it. The localize/normalize functionality is provided by the .astimezone() method which when called without arguments will attach an appropriate fixed offset timezone to a datetime object. You can then add timedeltas to the result and stay within a "fictitious" fixed offset timezone that extends indefinitely in both directions. To get back to the actual civil time - you call .astimezone() again. This gives you what we call here a "timeline" arithmetic and occasionally it is preferable to doing arithmetic in UTC. (Effectively you do arithmetic in local standard time instead of UTC.) Using a fixed offset timezone other than UTC for timeline arithmetic is preferable in timezones that are far enough from UTC that business hours straddle UTC midnight.
-- https://mail.python.org/mailman/listinfo/python-list
