[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