[Datetime-SIG] Clearing up terminology
ISAAC J SCHWABACHER
ischwabacher at wisc.edu
Thu Jul 30 21:55:36 CEST 2015
[Tim]
> 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?
ijs
More information about the Datetime-SIG
mailing list