Re: [DatetimeSIG] Clearing up terminology
[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@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_dstlike 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 tzaware 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 tzaware 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 timedeltaish 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).
participants (1)

Tim Peters