[Datetime-SIG] Clearing up terminology

[Tim Peters]

[Tim]
>> "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.

[Chris Barker <chris.barker at noaa.gov>]
> Which is really something that needs to addressed!

Eh.  It doesn't really scratch an itch I have, although I realize
other people have already scratched down to their bones ;-)  Because
of the latter, Python should address it.

In the few cases I've needed (what Guido now calls "strict" or
"timeline") arithmetic, it's just a matter of converting to UTC, doing
the arithmetic there, and converting back to the originat tzinfo.
These are easy, straightforward functions to write.  They don't always
get the right answers in the "problem hours" involving DST
transitions, but that's not a problem with arithmetic, it's due to
that conversions alone can't always deliver the right answers (due to
the absence of a correctly updated is_dst-like information in datetime
objects).


> 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".

I haven't had made time to study the glossary hard, so have no opinion
as to whether it's adequate (or even sensible) for Python's purposes.

> 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?

As I lack expert knowledge of what "Period Arithmetic" means
_exactly_,. I can't answer your question.

But, really, it's dead easy to understand what datetime actually does:
 its _model_ is "naive time".  In naive time, a day _is_ exactly 24
hours, and not even the _concept_ of "time zone" exists.  Everything
(well, almost ;-) ) about how arithmetic works _follows_ from that
view of the world.  The only irregularities are due to the lumpy
nature of the Gregorian calendar (leap years, and months with
differing numbers of days).  There's no such thing as "time zones" in
the naive time model.

What endlessly screws some people up is that (almost) all that remains
strictly true for arithmetic on datetime objects that _do_ have a
fully functinoal tzinfo member.  They _still_ follow the "naive time"
model.  The presence or absence of a tzinfo member makes (almost) no
difference at all to arithmetic.  I personally would have preferred
that "aware" datetime objects use strict/timeline arithmetic instead,
but it's not a big deal to me either way.


> ...
> Sure -- but we really need the docs to clarify what the heck happens when
> you have a tz-aware datetime.

Nothing at all changes about the arithmetic, _except_ when subtracting
two aware datetime objects.  Then the subtraction (in effect) converts
both to UTC before subtracting.  Because when mixing datetimes from
_different_ "time zones", there's no plausible justification for
considering them to both be in the _same_ "naive time".  So in that
specific case, strict/timeline arithmetic is done.  And that's the
source of the repeated "(almost)" repetitions earlier.

Ah, BTW, comparison of two aware dateimes also acts in strict/timeline
fashion.  In my head, that's a consequence of how subtraction works,
but not everyone has the benefit of my mental afflictions ;-)


> I'd offer to write a patch for the docs, but as you can see, I'm still
> pretty confused!

Then, by all means, wait until clarity erupts ;-)  I think the only
strong clues about this now are buried in footnotes on the docs
covering datetime's arithmetic operators.  They explain exactly _what_
happens, but with no explanation of _why_ it works that way.  "That
sucks" would be fair.

> ...
> Well, yes. I was ecstatic when datetime was introduced, and have found it
> very, very useful since then.

Me too.  Honest, has it actually become _less_ useful to you just
because this batch of messages started?

As many in the Python world can tell you, I _can_ be as obnoxious
about being "anally correct" as anyone, and far more so than most.  I
disliked "naive time" at first glance.  I was forced ;-) to implement
it (Guido was my boss in real life at the time).  But as I used it, I
grew to like it a whole lot.  Provided you embrace the "naive time"
model for what it is, datetime is great.  Nevertheless, I would have
preferred that aware datetimes use strict/timeline arithmetic in all
cases, and would have _greatly_ preferred addressing is_dst from the
start.

> However, not for "calendar operations" (Period Arithmetic) , nor for tz-aware
> datetimes. (because I don't have much need for these)

Then you _live_ in a "naive time" world.

> 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.

Without taking time now to try to learn exactly what all the new buzz
phrases mean, mixed datetime/timedelta arithemtic was never intended
to handle all possible, or even all common, use cases for Period
Arithmetic.  Just the ones with inarguably clear meanings _in_ the
naive time model.  There is no possible argument about what, e.g.,
"day" or "week" mean in naive time:  in naive time, their meanings as
microsecond durations and as deltas between datetimes are the same.
But as microsecond durations, "month" and "year" have no clear
meanings even in naive time, so timedelta doesn't support those units.

> The implementation could fully support Duration Arithmetic, so it's a bit of
> shame that that wasn't chosen in the first place.

A timedelta represents a specific number of microseconds.  That's all
it does.  When adding/subtracting to;from a datetime, the result is
that many microseconds removed in "naive time".  That timedelta's
"day"  is equivalent to naive time's "day" is a consequence of the
naive time model.  They work flawlessly in tandem.  They may not work
worth shit together in any other model of time.  Note that Guido has
already proposed adding new timedelta-ish classes, to "do the right
things" for other models of time (well, _the_ other model:  the messy
ways local clocks actually work, although still ignoring the
possibility of leap seconds) and/or fancier kinds of calendar
operations (a commonly used phrase in these messages, which I won't
presume to translate into the new vocabulary I haven't yet mastered).