[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement
tim.peters at gmail.com
Sun Aug 16 20:34:51 CEST 2015
> PEP 495  is a deliberately minimalistic proposal to remove an
> ambiguity in representing some local times as datetime.datetime
Just noting that the "Guidelines for new tzinfo implementations"
section uses the term "hour" when discussing DST transitions, which it
hour = timedelta(hours=1)
The confusion here is that DST adjustments aren't always an hour.
Running an ad hoc Python script over the Olson data files, I get this
distribution of DST adjustments (the string value followed by the
number of times it appears):
'1' 3 # best I can tell, this means '1:00" (one hour)
Almost all of these apply only to historical dates, but since we're
trying to cater to things that don't matter anyway ... ;-)
For another annoyance, it looks like at least one place in the world
has more than one kind of DST during each year. Here from the
discussion of Antarctica/Troll in the "antarctica" file:
# I recently had a long dialog about this with the developer of timegenie.com.
# In the absence of specific dates, he decided to choose some likely ones:
# GMT +1 - From March 1 to the last Sunday in March
# GMT +2 - From the last Sunday in March until the last Sunday in October
# GMT +1 - From the last Sunday in October until November 7
# GMT +0 - From November 7 until March 1
So, top to bottom, the DST offset changes from 0 to 1, then from 1 to
2, then back to 1 again, and finally to 0. The rules for that are
currently commented out, because the comments note that zic had to be
changed (in 2014) to handle them correctly, and they don't want to
uncomment the rules until the most recent zic is widely adopted. The
current rules ignore the two periods with the +1 adjustment, so DST
jumps between 0 and +2 in Antarctica/Troll.
In any case, that means references to "zero" in the DST discussion are
also too specific.
If I were you, I'd leave the text alone, but add a footnote explaining
that things may need to be adjusted in the obvious ways for timezones
with oddball DST adjustments and/or more than one kind of DST per
year. I don't see any problems here `first' doesn't handle in theory
- these headaches belong to tzinfo implementers.
More information about the Datetime-SIG