[tz] Possible bug in the tz database

[Matt Johnson]

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 at fastmail.us
> To: tz at 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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150606/ef5dedf9/attachment.html>