[Datetime-SIG] Datetime arithmetic proposal

[Tim Peters]

[Felipe Ochoa]
>> ...
>> B. Implement `.get_offset_time(self, hours, minutes, seconds, ms)` and
>> `.compute_duration(self, other_dt)` methods for "aware arithmetic." (I.e.,
>> congruent to 'convert to UTC, increment, convert back')


[Chris Barker <chris.barker at noaa.gov>]
> what the heck would that mean? the timedeltas already do that -- what they
> don't do is calendar maniplutaions -- things like "this same time tomorrow"
> -- or tomorrow morning at 7:00am.

We've been through this before, and it's been discussed literally
dozens of times on python-dev recently.  So I refuse to use any "word
salad" to try to describe anything anymore - nobody can hear anything
anyone else says ;-)

Start with a datetime object representing day 23 in some month and
some year, and time 4:56.

Add timedelta(hours=24) to that, or add timedelta(days=1) to that, or
(there are many other possible spellings of the same thing) and you
will ALWAYS get back a timedelta object representing day 24 in the
same month, the same year, the same time (4:56), and with the same
tzinfo member.  It makes no difference which year, no difference which
month, and no difference which tzinfo member you started with.  You
always get back "tomorrow at the same time (as shown on the local
clock)".  And, yes, the two _may_ be 23 hours apart, or 24 hours, or
25 hours, or even (e.g.,) 23 hours and 15 minutes apart as measured by
a stopwatch, depending on the rules implemented by the tzinfo member.
The tzinfo member is never consulted about anything in a datetime +
timedelta operation.  The tzinfo member is ignored (apart from being
copied to the result datetime).  The arithmetic is done exactly the
same as for a naive datetime object.

I think you're calling that a "calendar operation".  Other people call
it "naive datetime arithmetic", some call it "broken", Guido calls it
a feature of his "naive time" design, some call it the "a day is
always 24 hours rule", and some call it the "s day is not always 24
hours rule".  That's why it's impossible to understand anyone without
an excruciatingly detailed example ;-)

In any case, that's what Python has always done.  It won't change, not
even in the imaginary "backward compatibility is irrelevant" Python 4
(because Guido still favors this design).

That's for the builtin datetime module and its already-existing
objects and operations.  There's no backward-compatibility constraint
on anything new, of course.