On Thu, Jul 30, 2015 at 2:19 PM, Ethan Furman email@example.com 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.
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....)