[tz] Possible bug in the tz database

[Howard Hinnant]

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