On Thu, Jul 30, 2015 at 9:45 AM, Tim Peters <[email protected]> wrote:
> Oops! Forgot one: > > [Guido] > > ... create new timedelta-ish classes that implement "human" arithmetic > > Note that there's an annoying inelegance here: after > > datetime2 = datetime1 + timedeltaish # or subtraction > > then what does: > > datetime2 - datetime1 > > produce? yup -- with two (or three!) different flavors of a delta, what can you do? > Of course that's never a problem today. If the inelegance is thought > to be unbearable, I suppose new timedelta-ish classes could provide an > explicit class method to subtract datetime instances (yielding "the > right" timedelta-ish object of the class). > Which makes me think -- is it important that there is ONE datetime object, with two delta objects? or should there be two timedelta objects? That might provide a more obvious API -- which kind of arithmetic do you want to do with these? But also, it would open the door to different implementations: for instance, if your primary goal is to support Duration arithmetic, it may make sense to store the datetime in UTC always, and only mess with time zones on I/O. And you may want to store as "microseconds since year 1" directly as well. Of course, easy conversion between the two would be critical. -Chris -- 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/
