On Thu, Jul 30, 2015 at 6:03 PM, Tim Peters tim.peters@gmail.com wrote:

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

Cool. I missed that one message out of 100s. :-)

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

I assume you meant naive, not native.

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.

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 ;-)

It was definitely naive. :-)

...

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

And yet that is what I meant, i.e., calling the current arithmetic for tz-aware objects classic, because I wanted to avoid naming it naive (because of the aforementioned verbal mess).

...

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

Yes, I meant to introduce human arithmetic as a third form, to support adding e.g. months or years, while classic and strict arithmetic shouldn't. (Since timedelta doesn't keep its days and seconds separated, it's not really a Period, so I think it shouldn't be extended further. And adding months is a requirement for human arithmetic -- e.g. I was called a bad word on Twitter yesterday because timedelta doesn't support months.)

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 ;-)

Sure.

...

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 agree. :-)

...

...

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.

I stand corrected. My memory seems to be failing -- I also thought there was a datetime PEP, but I guess we avoided the PEP process (even though datetime was added in 2.3, well after PEP 1 was written) because we were all working in the same office. (Or do I misremember that too? :-)