<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 26, 2015 at 11:33 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":11t" class="a3s" style="overflow:hidden">As a user, if the apparent semantics of time zone aware date time<br>
arithmetic are accurately represented by "convert time to UTC -><br>
perform arithmetic -> convert back to stated timezone", then I *don't<br>
care* how that is implemented internally.<br>
<br>
This is the aspect Tim is pointing out is a change from the original<br>
design of the time zone aware arithmetic in the datetime module. I<br>
personally think its a change worth making that reflects additional<br>
decades of experience with time zone aware datetime arithmetic, but<br>
the PEP should be clear that it *is* a change.<br></div></blockquote><div><br></div><div>These semantics are already available in python 3:</div><div><br></div><div><div>>>> t = datetime(2015, 3, 7, 17, tzinfo=timezone.utc).astimezone()</div><div>>>> t.strftime('%D %T %z %Z')</div><div>'03/07/15 12:00:00 -0500 EST'</div><div>>>> (t+timedelta(1)).strftime('%D %T %z %Z')</div><div>'03/08/15 12:00:00 -0500 EST'   # a valid time, but not what you see on the wall clock</div><div>>>> (t+timedelta(1)).astimezone().strftime('%D %T %z %Z')</div><div>'03/08/15 13:00:00 -0400 EDT'   # this is what the wall clock would show</div></div><div> </div><div>Once CPython starts vendoring a complete timezone database, it would be</div><div>trivial to extend .astimezone() so that things like t.astimezone('US/Eastern')</div><div>work as expected.</div><div><br></div><div>What is somewhat more challenging, is implementing a tzinfo subclass that can be used</div><div>to construct datetime instances with the following behavior:</div><div><br></div><div>>>> t = datetime(2015, 3, 7, 12, tzinfo=timezone('US/Eastern'))<br></div><div>>>> t.strftime('%D %T %z %Z')</div><div>'03/07/15 12:00:00 -0500 EST'</div><div>>>> (t + timedelta(1)).strftime('%D %T %z %Z')</div><div>'03/08/15 12:00:00 -0400 EDT'<br></div><div><br></div><div>The solution to this problem has been provided as a documentation example [1] for many years,</div><div>but also for many years it contained a subtle bug [2] which illustrates that one has to be careful</div><div>implementing those things.</div><div><br></div><div>Although the examples [1] in the documentation only cover simple US timezones, they cover</div><div>a case of changing DST rules and changing STD rules can be implemented similarly.</div><div><br></div><div>Whether we want such tzinfo implementations in stdlib, is a valid question, but it should be</div><div>completely orthogonal to the question of vendoring a TZ database.</div><div><br></div><div>If we agree that vendoring a TZ database is a good thing, we can make</div><div>.astimezone() understand how to construct a fixed offset timezone from a location</div><div>and call it a day.</div><div><br></div><div>[1]: <a href="https://hg.python.org/cpython/file/default/Doc/includes/tzinfo-examples.py">https://hg.python.org/cpython/file/default/Doc/includes/tzinfo-examples.py</a></div><div>[2]: <a href="http://bugs.python.org/issue9063">http://bugs.python.org/issue9063</a></div></div><br><br></div></div>