[Datetime-SIG] Calendar vs timespan calculations...

Guido van Rossum guido at python.org
Thu Jul 30 11:25:16 CEST 2015


On Thu, Jul 30, 2015 at 2:31 AM, Chris Barker <chris.barker at noaa.gov> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150730/306add74/attachment.html>


More information about the Datetime-SIG mailing list