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.