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

[Chris Angelico]

On Wed, Jul 29, 2015 at 1:13 PM, Tim Peters <tim.peters at gmail.com> wrote:
> [Chris Angelico <rosuav at gmail.com>]
>> What if the existing timedelta is left as-is,
>
> That much isn't a "what if" - that much is a requirement ;-)

Heh, sure. Vagaries of the English language sometimes result in an
apparent suggestion like this :)

>> and a new calendardelta type is introduced? Instead of folding
>> everything down to a simple microsecond count, it would retain
>> the exact values it was given,
>> so calendardelta(days=1) != calendardelta(seconds=86400).
>> When you add a calendardelta to an aware datetime, it performs
>> what you're describing as calendar arithmetic
>
> That's what the _current_ timedelta already does (things like "same
> time tomorrow", "same time in 25000 weeks", and "same time plus an
> hour 57 days ago" are all trivially done already by datetime +
> timedelta operations).

Except that it isn't possible to distinguish "add 86400 seconds" from
"add 1 day". It's fine for adding to a naive datetime, as they're
equivalent, but they differ with aware datetimes - hence the notion of
having a different way to add to them.

The semantics would be that adding any unit to an aware datetime *will
not change* any unit of finer resolution, unless the result would
otherwise be impossible to represent. So when you add 1 day to 9AM
today, you get 9AM tomorrow; but when you add 24 hours to 9AM today,
you might get 10AM tomorrow, because one hour got snipped out of the
intervening night. Similarly, adding 1 year to Feb 23rd 2012 will
result in Feb 23rd 2013 (has added 366 days), but adding 1 year to Feb
23rd 2013 will add only 365 days; this is a concept that the current
timedelta simply can't handle, as it doesn't work in any unit larger
than the day.

There is one edge case that I'm aware of, and that's where the simple
calculation results in an invalid timestamp - either because the clock
jumps forward (DST switch) or because you would land on a leap day. In
each case, it's possible only when you're moving in a unit greater
than the one that's being adjusted - you can't land on Feb 29th 2015
by moving X days, because it'll count days right past it, so you must
have been moving months or years. When you move forward, the obvious
thing is to jump forward by a distance exactly equal to the gap - one
extra day to land on March 1st, or one extra hour to land at 3AM - but
I'm not sure what the best solution is when moving backward.

Are there any other nasty edge cases?

ChrisA