On Thu, Jul 30, 2015 at 2:19 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/30/2015 01:28 PM, Carl Meyer wrote:

[...] The _implementation_ can easily be explained [...]
I'd summarize it as "all arithmetic temporarily pretends all
datetimes are naive, and then blindly reattaches the original
 tzinfo member") [...]

This is the heart of the matter.  The problem is not the timedelta, which is simply a number of seconds, but with how datetime uses it.

conceptually yes, in the code? I don't know. 

which __add__method actually does the work?

But given backward compatibility, there is not [point in arguing out whether the current implementation is coherent, or wrong, or highly useful or????

It seems we have general consensus that both Period arithmetic and Duration Arithmetic with time zone aware datetime objects are useful.

And that the current implementation in the datetime module does not provide a complete (or even mostly complete) implementation of either of these.

And that we can't add functionality to timedelta to better support Period arithmetic without totally breaking backward compatibility

And that we can't change the way datetime+tzinfo+timedelta interact witout breaking backward compatibility.

So:

Some combination of a new and new timedeltas are required.

And we cannot change existing behavior, but we can add to it -- so a new option for datetime that told it to take dst switches into account so that the new datetime was in fact timedelta seconds away should do the trick.

hmm -- that might buy us Duration Arithmetic, but how do we get Period Arithmetic.

By the way -- which __add__ actually does the implementation? datetime's or timedelta's ?

(both are slots, so not easy to see the code....)

-CHB


--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov