Possible bug in the tz database
I’m new to this list, so please forgive me for my inexperience and lack of history. I am concerned about the timezone America/North_Dakota/Beula: Early of the local morning of 2010-11-07 the local timezone GMTOFF changed from -7:00 to -6:00, and the timezone abbreviation changed from MDT to CST. I am not questioning this historical fact. Rather I am concerned about exactly when it happened and does the tz database accurately reflect this event. Here are the relevant entries today: Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 -7:00 US M%sT 2010 Nov 7 2:00 -6:00 US C%sT Which says at 2:00am local time on 2010/Nov/07 the change from MDT to CST occurs. Local time is defined by GMTOFF == -7:00 + US timezone rules for 2010. Or in other words 2:00am + 7:00 + any daylight savings time adjustment. I’m sure I’m preaching to the choir with this audience. I think there is no dispute that: 2010-11-07 01:59:59 MDT == 2010-11-07 07:59:59 UTC At this point in time the GMTOFF == -7:00 and in the US rule SAVE == 1:00 for a total offset of -6:00. However according to US rules for this date, the local clock ticks from 01:59:59 MDT to 01:00:00 MST. To reach 2:00am local time we need to wait another hour: 2010-11-07 02:00:00 MST == 2010-11-07 09:00:00 UTC According to US time zone rules (speaking about the recognized practice in the US, not about tz database rules), there was no 2010-11-07 02:00:00 MDT. It simply did not exist. So 2010-11-07 02:00:00 local time in US rules is unambiguously a standard time, not a daylight savings time. Whereas the times [01:00:00, 01:59:59] *are* ambiguous (or more accurately described with a half-open range: [01:00:00, 02:00:00). Since 2010-11-07 02:00:00 is unambiguously a standard time, the database could read like this with no change in behavior: Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 -7:00 US M%sT 2010 Nov 7 2:00s -6:00 US C%sT But this data indicates that local time behaves as follows that morning: 2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 01:00:00 MST = 2010-11-07 08:00:00 UTC 2010-11-07 01:00:01 MST = 2010-11-07 08:00:01 UTC … 2010-11-07 01:59:59 MST = 2010-11-07 08:59:59 UTC 2010-11-07 03:00:00 CST = 2010-11-07 09:00:00 UTC 2010-11-07 03:00:01 CST = 2010-11-07 09:00:01 UTC However I believe the intended behavior is: 2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 02:00:00 CST = 2010-11-07 08:00:00 UTC 2010-11-07 02:00:01 CST = 2010-11-07 08:00:01 UTC I believe the tz database can be changed to give the desired behavior with: diff --git a/northamerica b/northamerica index 88423e6..aeaf12c 100644 --- a/northamerica +++ b/northamerica @@ -371,7 +371,7 @@ Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 # of 6h47'07". Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 - -7:00 US M%sT 2010 Nov 7 2:00 + -7:00 US M%sT 2010 Nov 7 1:00s -6:00 US C%sT # US mountain time, represented by Denver If I have misinterpreted the meanings of the fields to the tz database in some way, I would appreciate an education. I’ve reread all of the man pages and other documentation I can find, and haven’t been able to rectify this contradiction on my own. If this is indeed a bug that can be corrected, I am volunteering to detect and correct similar issues elsewhere in the database and generate a pull request for https://github.com/eggert/tz. Howard
Howard Hinnant wrote:
I would appreciate an education.
The intent is that the UNTIL column (which specifies a transition time) is interpreted as of the rules in effect before the transition. In the case you've identified, two transitions occur simultaneously. One is that DST is no longer in effect; the other, that the location moves from mountain to central time. In this case, the UNTIL column is interpreted without either change in effect, i.e., in mountain daylight time. Under this interpretation, the tz database is already correct and the patch you proposed would not change its behavior.
According to US time zone rules (speaking about the recognized practice in the US, not about tz database rules), there was no 2010-11-07 02:00:00 MDT. It simply did not exist.
Actually, I think the common practice in the US is to say that the clock moves backward from 02:00 to 01:00 local time, i.e., 02:00 and 01:00 are both observed twice on fall-back days. The tz database takes a stricter approach though, an approach derived from common computer practice: it says that 01:00 occurs twice but 02:00 occurs only once in generated time stamps. However, this approach does not apply to the UNTIL column, which commonly refers to a local time like 02:00 even when the computer-generated time stamps jump from 01:59.999...9 back to 01:00 or forward to 03:00 and never hit 02:00 exactly. Attached is a proposed patch to the documentation to try to make this a bit clearer.
On Sat, Jun 6, 2015, at 21:36, Howard Hinnant wrote:
But this data indicates that local time behaves as follows that morning:
2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 01:00:00 MST = 2010-11-07 08:00:00 UTC 2010-11-07 01:00:01 MST = 2010-11-07 08:00:01 UTC … 2010-11-07 01:59:59 MST = 2010-11-07 08:59:59 UTC 2010-11-07 03:00:00 CST = 2010-11-07 09:00:00 UTC 2010-11-07 03:00:01 CST = 2010-11-07 09:00:01 UTC
However I believe the intended behavior is:
2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 02:00:00 CST = 2010-11-07 08:00:00 UTC 2010-11-07 02:00:01 CST = 2010-11-07 08:00:01 UTC
My system's zdump output: America/North_Dakota/Beulah Sun Mar 14 08:59:59 2010 UTC = Sun Mar 14 01:59:59 2010 MST isdst=0 America/North_Dakota/Beulah Sun Mar 14 09:00:00 2010 UTC = Sun Mar 14 03:00:00 2010 MDT isdst=1 America/North_Dakota/Beulah Sun Nov 7 07:59:59 2010 UTC = Sun Nov 7 01:59:59 2010 MDT isdst=1 America/North_Dakota/Beulah Sun Nov 7 08:00:00 2010 UTC = Sun Nov 7 02:00:00 2010 CST isdst=0 America/North_Dakota/Beulah Sun Mar 13 07:59:59 2011 UTC = Sun Mar 13 01:59:59 2011 CST isdst=0 America/North_Dakota/Beulah Sun Mar 13 08:00:00 2011 UTC = Sun Mar 13 03:00:00 2011 CDT isdst=1 In general, it's probably more useful to rely on zdump output, rather than working through interpreting the data by hand, for reasoning about what behavior a given piece of timezone data actually produces.
Keeping mind that there are other implementations that read the tzdata directly, I thought I would check a few that I'm familiar with.I checked Noda Time (C#), pytz (Python), and moment-timezone (JavaScript). They all correctly interpret this zone's change from MDT to CST as of 8:00 UTC, keeping the UTC-06:00 offset the whole time.I would expect if an implementation interpreted it incorrectly, there would be a one hour period where the zone used MST with a UTC-07:00 offset.
From: random832@fastmail.us To: tz@iana.org Date: Sat, 6 Jun 2015 23:30:23 -0400 Subject: Re: [tz] Possible bug in the tz database
On Sat, Jun 6, 2015, at 21:36, Howard Hinnant wrote:
But this data indicates that local time behaves as follows that morning:
2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 01:00:00 MST = 2010-11-07 08:00:00 UTC 2010-11-07 01:00:01 MST = 2010-11-07 08:00:01 UTC … 2010-11-07 01:59:59 MST = 2010-11-07 08:59:59 UTC 2010-11-07 03:00:00 CST = 2010-11-07 09:00:00 UTC 2010-11-07 03:00:01 CST = 2010-11-07 09:00:01 UTC
However I believe the intended behavior is:
2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 02:00:00 CST = 2010-11-07 08:00:00 UTC 2010-11-07 02:00:01 CST = 2010-11-07 08:00:01 UTC
My system's zdump output: America/North_Dakota/Beulah Sun Mar 14 08:59:59 2010 UTC = Sun Mar 14 01:59:59 2010 MST isdst=0 America/North_Dakota/Beulah Sun Mar 14 09:00:00 2010 UTC = Sun Mar 14 03:00:00 2010 MDT isdst=1 America/North_Dakota/Beulah Sun Nov 7 07:59:59 2010 UTC = Sun Nov 7 01:59:59 2010 MDT isdst=1 America/North_Dakota/Beulah Sun Nov 7 08:00:00 2010 UTC = Sun Nov 7 02:00:00 2010 CST isdst=0 America/North_Dakota/Beulah Sun Mar 13 07:59:59 2011 UTC = Sun Mar 13 01:59:59 2011 CST isdst=0 America/North_Dakota/Beulah Sun Mar 13 08:00:00 2011 UTC = Sun Mar 13 03:00:00 2011 CDT isdst=1
In general, it's probably more useful to rely on zdump output, rather than working through interpreting the data by hand, for reasoning about what behavior a given piece of timezone data actually produces.
Thanks everyone for the clarification on the meaning of the db entries and of the confirmation that existing parsers are doing what I expected they should. Howard
participants (5)
-
Howard Hinnant -
Matt Johnson -
Paul Eggert -
random832＠fastmail.us -
Ángel González