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.