On Thu, Jul 30, 2015 at 2:25 AM, Guido van Rossum <[email protected]> wrote:
> Perhaps the original intent was that "days" means calendar days, and for >> naive datetimes, it turns out to be the same thing, but that is not what >> the implementation does, and given that it supports seconds and >> microseconds, but not months or years, the API is pretty clearly designed >> for timespans, not calendar definitions. >> > > I can assure you that the implementation carefully matches the original > intent. > I apologise -- I'm afraid I've dragged this out more than necessary due to my misunderstanding -- see my other posts if anyone cases about that. > Even if I wouldn't design it that way today (which honestly I haven't > decided whether I would or not) I don't want to change anything about the > observable behavior[1] that would give a different outcome, > of course not. > no matter how much more "correct" you believe a different outcome would be. > There is "correct" and incorrect, but I"m not arguing that anything is incorrect about the current behavior -- I thought a timedelta was a duration, but I was wrong, it is a Period in units of days (I think!), and sure it apparently does that right. The docs sure need clarifying, though. > The road to improvement that I encourage everyone to explore: add an > is_dst flag (with a different name) > +1 absolutely > and create new timedelta-ish classes that implement "human" arithmetic > (similar to what pytz offers) and "strict" arithmetic (similar to > [NJ]odaTime, IIUC). Separately, standardized access in the stdlib to a tz > database (see another thread). > Sounds good to me -- both are very useful, and clearly defining which is which makes lots of sense. > [1] The *implementation* may change, but not in a way that changes > observable behavior, except for the addition of new attributes, parameters > and/or methods. > hmm -- given that, then perhaps timedelta could be extended to do more rich Period arithmetic without breaking the current behavior. But I suppose the new PeriodDelta object would have to be fleshed out first, to see if that's possible. -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/
