[Datetime-SIG] Are there any "correct" implementations of tzinfo?

Tim Peters tim.peters at gmail.com
Tue Sep 15 02:31:24 CEST 2015


[Alexander Belopolsky]
>> ...
>> >>> from datetime import *
>> >>> from datetimetester import Eastern
>> >>> UTC = timezone.utc
>> >>> a = datetime(2002, 4, 7, 1, 40, tzinfo=Eastern)
>> >>> b = datetime(2002, 4, 7, 2, 20, tzinfo=Eastern)
>> >>> a < b
>> True
>> >>> a.astimezone(UTC) < b.astimezone(UTC)
>> False

[Random832 <random832 at fastmail.com>]
> ...
> I don't know how your datetimetester works, so this is a bit of a black
> box to me - correct me if any of the below is wrong:
>
> I assume that 2002-04-07 is the morning of the "spring forward"
> transition of that year. Therefore, it's worth noting, the time in "b"
> is one that doesn't actually exist. I actually did mention, in one of my
> messages on the subject, that "spring forward" times were an exception -
> the *only* exception, to the invariant, but that's been lost in a few of
> my repetitions.
>
> I'm going to assume that the interpretations that led to your results
> are:
> a = 2002-04-07 01:40:00 -0500 = 2002-04-07 06:40:00 Z
> b = 2002-04-07 02:20:00 -0400 = 2002-04-07 06:20:00 Z
>
> I don't think this is a reasonable value for b.astimezone(UTC) to have.

I can explain the thinking here:  in "naive time", there's no such
thing as "missing time".  Indeed, if you watch an old-fashioned
mechanical clock near the time DST starts, you'll see it change from
1:59 to 2:00 to 2:01 ... to 2:20.  Since it's now ">= 2:00" on the
local clock, US rules say you're now in daylight time.  So the only
UTC offset that _does_ make sense is the US/Eastern daylight offset:
-4.

"But you forgot to set the clock ahead, so this should _really_ be
considered as still being in standard time!" is an argument outside
the naive time model.  "Set the clock ahead?  That's insane!  My clock
keeps perfect time - why would I break it?" ;-)

The bottom-line lesson being the same as always:  if you need to care
about folds and gaps, in datetime it's intended that you work in UTC
instead (or some other fixed-offset zone).


More information about the Datetime-SIG mailing list