[Datetime-SIG] The BDFL's take

[Lennart Regebro]

On Wed, Jul 29, 2015 at 4:37 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Jul 29, 2015 at 10:06 AM, Lennart Regebro <regebro at gmail.com> wrote:
>>> - Design a new module with a separate API for "human time manipulation".
>>
>> That would be reasonable. Unfortunately, that's what datetime tries to
>> implement already, but does so only a little bit. It's the non-human
>> (ie correct) arithmetic that is lacking, for datetimes that have
>> timezones.
>
> Can you provide a specific example that demonstrate that something is
> lacking?

>>> from datetime import *
>>> from dateutil.zoneinfo import gettz

>>> est = gettz('US/Eastern')
>>> dt1 = datetime(2014, 11, 2, 0, 30, tzinfo=est)
>>> dt1
datetime.datetime(2014, 11, 2, 0, 30, tzinfo=tzfile('America/New_York'))
>>> dt1 + timedelta(hours=1)
datetime.datetime(2014, 11, 2, 1, 30, tzinfo=tzfile('America/New_York'))
>>> dt1 + timedelta(hours=2)
datetime.datetime(2014, 11, 2, 2, 30, tzinfo=tzfile('America/New_York'))

In fact at 2am, the hour swithes back one hour, so two hours after
00:30 is 01:30. Yes, 01:30 happens twice. This means that the above
calculations are incorrect.
It is the "naive" or "human" implementation here, where adding one
hour actually adds two.

And further:

>>> dt = datetime(2014, 3, 9, 0, 30, tzinfo=est)
>>> dt + timedelta(hours=1)
datetime.datetime(2014, 3, 9, 1, 30, tzinfo=tzfile('America/New_York'))
>>> dt + timedelta(hours=2)
datetime.datetime(2014, 3, 9, 2, 30, tzinfo=tzfile('America/New_York'))

Oups! At 2:30 that day, the clock is shifted forward one hour.
2:30 am on the 9th of March 2014 is a time that did not exist in New York!
This is "human" arithmetic, ie, the arithmetic that you would expect
if you forget that timezones change.

> So I really don't understand your complaint.  Both "human" and "non-human"
> calculations are easy with the current implementation of the datetime module.

I disagree with that. To make "non-human" (ie correct) calculations I
have to first convert the timezone to UTC, then do the calculations,
then convert it back. Two out those three things are unnecessary, it's
perfectly possible to make an implementation that doesn't need them.

> Since it does not include any "human" tzinfo implementations out of the box,
> many people say that  "human time manipulation" is lacking.  However,
>  "human time manipulation" includes more than automatic DST transitions:
> it also includes adding months, years and possibly quarters and other units.

I agree. Hence my statement that "human" manipulation is what datetime
implements, but only partly.

> To me the perfect example of the "human time manipulation" is the GNU
> date utility:
>
> $ date -d "last friday"
> Fri Jul 24 00:00:00 EDT 2015
> $ date -d "next month"
> Sat Aug 29 10:35:46 EDT 2015
> $ date -d "week ago"
> Wed Jul 22 10:36:47 EDT 2015

Yup, that would be nice.