On Thu, Jul 30, 2015 at 11:33 AM, Ethan Furman ethan@stoneleaf.us wrote:

Instead of making a new timedelta object, which, after all, represents exactly what it says, why don't we make a new DateTime and Time that do the duration arithmetic?

I like that -- as I read Tim's last post, it struck me that the focus as been on the timedelta object, but that's not where the confusion is -- you are right: a timedelta object represents a span of time, in microseconds. exactly what it says.

The confusion comes in when a timedelta interacts with a datetime and a tzinfo object.

I'm not sure where in the code the actual logic lies, if it does (or could) lie with the DurationDateTime object, then that object coulds use the existing timedelta object for its delta.

On the other hand, a PeriodDateTime object could not use the existing timedelta object -- as it can only represent an actual time span, and not something like "months" or "years".

And that would clear up the "what kind of delta to return from subtraction" issue.

Also -- it would open the door to a different implementation of datetime and timezones -- i.e. always store UTC, translate to the prescribed time zone on I/O.

A use case I'm not sure about though -- how often would folks need to do both kinds of arithmetic on the same datetime objects? If that's a common use case, it would be a shame to split that objects into different types.

-CHB