On Thu, Jul 30, 2015 at 2:31 AM, Chris Barker <[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. 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, no matter how much more "correct" you believe a different outcome would be. The deprecation time would have be measured in decades. The road to improvement that I encourage everyone to explore: add an is_dst flag (with a different name) 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). [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. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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/
