[Guido]
> ...
> I also never meant the term "naive" to be used for the existing arithmetic
> rules for tz-aware datetime objects -- I always meant "naive" to refer to
> tz-less datetime objects.

"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.   This batch of
messages needed to call it _something_, so I made something up.

The docs do briefly explain the "native time" _model_ (and acknowledge
that more than one kind of model is possible).

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

Which is an unfortunate verbal mess, in large part because "naive
arithmetic" is used for _both_ what the docs call "naive objects" and
"aware objects".  Then again, calling _anything_ "naive" in the docs
was probably also unfortunate from the start ;-)

> I would prefer something like "classic arithmetic" for tz-aware datetime objects.

Read literally, that doesn't make sense to me, and I can't tease out
the intent.  That is, calling an object (whatever it is) a kind of
arithmetic (whatever it is) doesn't make sense to me.  I had guessed,
that you wanted to call the kind of _arithmetic_ currently implemented
"classic arithmetic". but in the next sentence you seem to want to
call that "human arithmetic":

> We can then introduce two new terms for different forms of arithmetic:
> "human arithmetic" for the form that can do things like "+ 2 months" in a
> way that (mostly) matches human expectations, and "strict arithmetic" for
> the form that Lennart needs (essentially move a specific number of seconds
> along UTC).

Do you really intend that we use all three:  "classic arithmetic",
"human arithmetic", and "strict arithmetic"?.  If so, I don't grasp
the intended distinction between "classic" and "human".(both seem to
be the same as what I've been calling "naive arithmetic":  the
arithmetic Python currently implements for binary arithmetic operators
involving at least one datetime object).

Anyway, because "strict arithmetic" more-or-less literally means
"arithmetic that wholly satisfies the requirements of a given model",
in isolation the phrase leaves the question of _which_ model open.
So, as was suggested later in the thread, I'd prefer "timeline
arithmetic" (and couldn't care less whether it's called "timeline",
"time line", or both).  And I'll conveniently overlook that "timeline
arithmetic" on its own leaves open _which_ timeline (naive or
timezone) is intended ;-)

> FWIW (not much, we're stuck with it now), my intention with classic
> arithmetic was to approximate human arithmetic, but only for cases that
> didn't require messy heuristics such as "Feb 29, 2016 plus one year" or "Jan
> 31, 1956 minus 9 months".

I always viewed the _model_ ("naive time") as primary.  Specific
arithmetic requirements (for builtin arithmetic operators) then
necessarily followed from the choice of model.  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.

...

> I also (naively :-) assumed that people interested in strict arithmetic would
> just keep using the POSIX timestamps used by the time module.



>> (BTW, historically, early versions of Python datetime had a separate
>> datetime subclass called datetimetz (IIRC), but the final design got
>> rid of this unnecessary complexity.)

> I don't believe that was ever released, but it's possible we contemplated
> that and even implemented it in an early pure-Python prototype.

FWIW, IIRC it did exist in an early prototype but was discarded before
it was even halfway implemented.