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.
[ijs] I thought I understood what you were saying until now, but through this entire discussion I have been under the impression that you felt the exact opposite of that last sentence (except for the not being a big deal part).
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 ;-)
So once we have an is_dst bit, what will be the result of
tz = timezone('America/Chicago') datetime(2013, 11, 3, 1, 30, tzinfo=tz, is_dst=True) - datetime(2013, 11, 3, 1, 0, tzinfo=tz, is_dst=False)
? How can it be consistent with current behavior and be anything other than timedelta(0, 1800), even though the first time preceded the second?