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

[Chris Barker - NOAA Federal]

1. Datetime arithmetic
>>     a) datetime +/- timedelta
>>         ii. Aware (with tzinfo) datetime objects
>
> If the math is done in UTC, then there is no issue, yes? the timedelta is
> added or subtracted, and the result has the same tzinfo object.


If I've understood correctly, this is one of the bigger points of
contention. Specifically, the following operation is quite polarizing:
`datetime(2015, 3, 7, 13, 0, tzinfo=zoneinfo('America/New_York') ) +
timedelta(days=1)`

It raises the following two questions:
* Should `days=1` be interpreted the same as `hours=24`?


Yes, absolutely!

* If it is interpreted the same, should the addition be "naive" (not
adjusting for the jump from 1:59 to 3:00) or "aware"


If it is 24 hours, then there's no question.

So the question really is: should the datetime module provide what I've
been calling "calendar operations" ?

Yes, that would be very useful, but it's a heck of a lot more complicated
than just redefine what a timedelta(days=1) means. And particularly with
backward compatibility in mind, it definitely should not be done with that
API.

If people really are THAT prone to confusion that a day means 24 hours,
then we should consider deprecating "days" as a valid unit for a timedelta.

Current semantics call for the answers to be "yes" and "naive"


Here are the semantics again -- there is nothing naive about subtracting
and adding 24 hours. The problem here is that people are conflating a "day"
meaning 24 hours and a "day" meaning a numbered entity on a calendar. The
two are related, but totally different in meaning.

And sorry to get pedantic here, but backwards compatibility aside, I, for
one, would be very surprised if a timedelta(days=1) ever meant anything
other than 24 hours depending on context!

    b) datetime - datetime
>
>         ii. When both have same tzinfo
>
> Just do the math. Store as UTC makes it easy. return a timedelta.


This is another contentious issue. What do you want `datetime(2015, 3, 8,
13, tzinfo=zoneinfo('America/New_York')) - datetime(2015, 3, 7, 13,
tzinfo=zoneinfo('America/New_York'))` to be? There's a camp for
`timedelta(seconds=24 * 60 * 60)` and a


Assuming I've got the DST thing right here -- god no! In that time zone,
those time stamps are NOT 24 hrs apart! You'd better not mess with that!!!!

I'm going to indulge for a minute here: IF there was such a thing as a
calendar_delta object of some sort, then you might want one with a value of
one day there. But certainly not anything with a value of 24 *3600 seconds!

Does anyone really want that?

Note that this is s good argument for what calendar operations are so
complex.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150728/4b016d91/attachment.html>