On Thu, Jul 30, 2015 at 11:33 AM, Ethan Furman <[email protected]> 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 -- 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 [email protected]
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
