[Datetime-SIG] Clearing up terminology

[Felipe Ochoa]

I like the terms Period arithmetic and duration arithmetic. In those terms,
what we currently have is the following:

* "local/naive" datetime (no tzinfo) + timedelta is period arithmetic,
where timedelta is a restricted form of period that supports only days,
hours, minutes, seconds, and milliseconds. (Which is equivalent to
mixed-radix seconds, as Tim has pointed out)

* "aware" datetime (with tzinfo) + timedelta is sort of like period
arithmetic, though Noda doesn't define this operation. It is equivalent to:
1) remove the tzinfo to get a local/naive dt 2) perform period arithmetic
3) attach the tzinfo again to get an aware dt. I'm fine extending the Noda
definition of "period arithmetic" to cover this case

I think Guido and others have suggested we add Duration and Period objects
which will implement datetime arithmetic just like in Noda. The only
difference in our model would be that instead of LocalDateTime vs
ZonedDateTime, we have just datetime, with and without tzinfo. I am very
much +1 for this idea, and will write up a Duration object in the next
couple of days

-Felipe


On Thursday, July 30, 2015, Chris Barker <chris.barker at noaa.gov> wrote:

> On Thu, Jul 30, 2015 at 9:03 AM, Tim Peters <tim.peters at gmail.com
> <javascript:_e(%7B%7D,'cvml','tim.peters at gmail.com');>> wrote:
>
>> "Naive arithmetic" was my neologism, starting in this batch of
>> messages.  The docs don't call the arithmetic anything, or acknowledge
>> that more than one kind of arithmetic is possible.
>
>
> Which is really something that needs to addressed!
>
>
>>  This batch of
>> messages needed to call it _something_, so I made something up.
>>
>
> Can we just use the Glossary borrowed from Noda? It doesn't define an
> "arithmetic", but if we need that term, it could be "Period Arithmetic" and
> "Duration Arithmetic".
>
> And I had assumed that your "naive arithmetic" was Duration arithmetic --
> i.e. a day is 24 hours, but apparently not. I'm still confused as to how
> you can: (paraphrasing my understanding of your earlier post):
>
> Convert the datetime to a timedelta from year 1 -- add the timedelta --
> convert back to a datetime. I suppose it's a failure of mine to understand
> how datetime uses the tzinfo object, but this description sure sounds to me
> like you'd get a datetime that really represented 24 hours later, not 23 or
> 25 (or something else...)
>
> Anyway, my current understanding is that the current implementation of
> datetime and timedelta is "Period Arithmetic", with only Periods defined in
> units of days (fraction days, down to microsecond resolution).
>
> Is that correct?
>
> The kind of arithmetic
>> Python implements is the only kind that delivers correct answers
>> _within_ the naive time model,. so I've been calling it "naive
>> arithmetic" - in the sense of "the arithmetic behavior required by the
>> naive time model".
>>
>
> Sure -- but we really need the docs to clarify what the heck happens when
> you have a tz-aware datetime.
>
> I'd offer to write a patch for the docs, but as you can see, I'm still
> pretty confused!
>
>
>  In any case, while
>> mixed datetime/timedelta arithmetic supports only a small subset of
>> what people want in the way of "calendar operations", it is an
>> exceedingly useful subset on its own, _and_ in implementing fancier
>> operations.  It was a great start.
>>
>
> Well, yes. I was ecstatic when datetime was introduced, and have found it
> very, very useful since then. However, not for "calendar operations"
> (Period Arithmetic) , nor for tz-aware datetimes. (because I don't have
> much need for these)
>
> And unfortunately, I think the implementation of timedelta makes it
> impossible to extend to richer Period Arithmetic -- it fundamentally uses
> unit sof days, and has no way to encode any other "Period" unit -- i.e.
> months or years.
>
> The implementation could fully support Duration Arithmetic, so it's a bit
> of shame that that wasn't chosen in the first place.
>
> > I also (naively :-) assumed that people interested in strict arithmetic
>> would
>> > just keep using the POSIX timestamps used by the time module.
>>
>
> Well, that explains it -- but no, the time module is very limited and
> painful to use ;-) -- I was all for Datetime, even though my primary use
> cases are all Duration arithmetic.
>
> -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
> <javascript:_e(%7B%7D,'cvml','Chris.Barker at noaa.gov');>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150730/17baa929/attachment-0001.html>