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