<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 12, 2015 at 3:41 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> If there are not, maybe the intended semantics should go<br>
> by the wayside and be replaced by what pytz does.<br>
<br>
</span>Changing anything about default arithmetic behavior is not a<br>
possibility.  This has been beaten to death multiple times on this<br>
mailing list already, and I'm not volunteering for another round of it<br>
;-)</blockquote></div><br>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.  </div></div>