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