[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