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

Chris Barker chris.barker at noaa.gov
Thu Jul 30 18:46:15 CEST 2015


On Thu, Jul 30, 2015 at 2:25 AM, Guido van Rossum <guido at python.org> 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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150730/741ec677/attachment.html>


More information about the Datetime-SIG mailing list