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