[Datetime-SIG] The BDFL's take

[Alexander Belopolsky]

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?  As far as I can tell, the following is an example of a "non-human"
time arithmetics:

>>> t = datetime(2014, 1, 1, 17, tzinfo=timezone.utc).astimezone()
>>> t.strftime('%c %Z %z')
'Wed Jan  1 12:00:00 2014 EST -0500'
>>> u = t + timedelta(1)
>>> u.astimezone().strftime('%c %Z %z')
'Thu Jan  2 12:00:00 2014 EST -0500'

The only bit that I can see as "lacking" in this example is the
ability to elide the
second call to astimezone() and have a fancy tzinfo class that will take care
of the DST transition.  This is also possible, but by design, you get a "human"
answer in this case:

>>> t = datetime(2014,11,1,12,tzinfo=Eastern)
>>> t.strftime('%c %Z %z')
'Sat Nov  1 12:00:00 2014 EDT -0400'
>>> t += timedelta(1)
>>> t.strftime('%c %Z %z')
'Sun Nov  2 12:00:00 2014 EST -0500'

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

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