[Datetime-SIG] What's are the issues?

[Alexander Belopolsky]

On Tue, Jul 28, 2015 at 5:38 PM, Felipe Ochoa
<felipe.nospam.ochoa at gmail.com> wrote:
>
> Here is my best shot at categorizing the different outstanding design issues:
>

I would like to make sure that everyone is aware that we are not
designing in a vacuum.  Unlike
Python 2, Python 3 already has a decent amount of timezone support.
In fact, with some small
exceptions, I believe Python 3 datetime has a fairly complete support
for UTC and system local
timezones.

For the items below, I will try to briefly describe the status quo

> 1. Datetime arithmetic
>     a) datetime +/- timedelta
>         i. Naive (no tzinfo) datetime objects

This has been supported from the very beginning:

>>> t = datetime.now()
>>> t
datetime.datetime(2015, 7, 28, 19, 18, 59, 699588)
>>> t + timedelta(1)
datetime.datetime(2015, 7, 29, 19, 18, 59, 699588)

(no surprises here)

>         ii. Aware (with tzinfo) datetime objects

This works fine with the builtin timezone instances:

>>> t = datetime(2014,11,1,16,tzinfo=timezone.utc).astimezone()
>>> t.strftime("%c %Z %z")
'Sat Nov  1 12:00:00 2014 EDT -0400'
>>> u = t + timedelta(1)
>>> u.strftime("%c %Z %z")
'Sun Nov  2 12:00:00 2014 EDT -0400'

This may be a little surprising to those expecting to see DST to end, but the
legal time is one method call away:

>>> u.astimezone().strftime("%c %Z %z")
'Sun Nov  2 11:00:00 2014 EST -0500'


>     b) datetime - datetime
>         i. When both are naive
(Trust me: this part works!)

>         ii. When both have same tzinfo

>>> u - t
datetime.timedelta(1)

(Works.)

>         iii. When the two have different tzinfos

>>> u -  datetime(2014,11,1,16,tzinfo=timezone.utc)
datetime.timedelta(1)

(Works as well.)

> 2. Inter-timezone conversion

UTC to local just works.  Local to UTC "kind of" works:

>>> t = datetime.now()
>>> u = datetime.fromtimestamp(t.timestamp(), timezone.utc)
>>> u.strftime("%c %Z")
'Tue Jul 28 23:40:38 2015 UTC+00:00'

>     a) adding an isdst (or which) attribute
>     b) algorithm specification
>
> I think 1ai, 2bi, and 1biii are uncontroversial at this point, and 2a we have consensus on the need but not the name
>