Andy Lipscomb was right, there is an Opposite Case to the example we were looking at, but it is not when DST ends, and the offset is advanced, but when the offset is retreated, see ... UTC offset retreat at the moment of DST start (theoretical): Antlantic/Stanley Sun Sep 15 02:59:59 1985 UTC = Sat Sep 14 23:59:59 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 03:00:00 1985 UTC = Sat Sep 14 23:00:00 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 03:59:59 1985 UTC = Sat Sep 14 23:59:59 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 04:00:00 1985 UTC = Sun Sep 15 01:00:00 1985 FKDT isdst=1 UTC offset retreat at the moment of DST end (theoretical): America/Pangnirtung Sun Oct 31 05:59:59 1999 UTC = Sun Oct 31 01:59:59 1999 EDT isdst=1 America/Pangnirtung Sun Oct 31 06:00:00 1999 UTC = Sun Oct 31 01:00:00 1999 CDT isdst=1 America/Pangnirtung Sun Oct 31 06:59:59 1999 UTC = Sun Oct 31 01:59:59 1999 CDT isdst=1 America/Pangnirtung Sun Oct 31 07:00:00 1999 UTC = Sun Oct 31 01:00:00 1999 CST isdst=0 zic handles these cases the following way: Antlantic/Stanley Sun Sep 15 02:59:59 1985 UTC = Sat Sep 14 23:59:59 1985 FKST isdst=0 Antlantic/Stanley Sun Sep 15 03:00:00 1985 UTC = Sat Sep 15 00:00:00 1985 FKDT isdst=1 America/Pangnirtung Sun Oct 31 05:59:59 1999 UTC = Sun Oct 31 01:59:59 1999 EDT isdst=1 America/Pangnirtung Sun Oct 31 06:00:00 1999 UTC = Sun Oct 31 00:00:00 1999 CST isdst=0 Both are handled as desired by zic, so that in both cases zic reduces the two transitions to one. In World Time Explorer I'm implementing specific 1-hour transitions instead that mends the hiccup equivalent to the following: Zone America/Pangnirtung -4:22:56 - LMT 1884 -4:00 NT_YK A%sT 1995 Apr Sun>=1 2:00 -5:00 Canada E%sT 1999 Oct 31 2:00 + -6:00 - C%sT 1999 Oct 31 2:00 -6:00 Canada C%sT 2000 Oct 29 2:00 But I accept ado's argument that this is a bit cumbersome to implement and check. I have found 38 hiccups of this type in the tz database (that zic handles). The documentation is not explaining both cases, just the first one (even though zic handles it automatically). I suggest it to be changed to include this explicitly, for instance: "If a particular zone retreats UTC offset at the exact moment of DST start or DST end, zic produces a single transition to the new time instead of two transitions with an hour in between. At DST start the effect is that the wall clock is unchanged, while at DST end the effect is that the wall clock is advanced two hours in that moment." The formulation may not be perfect, but I thought that the original one was not particularly easy to understand either. Suggestions please! Regards, - Jesper When a mountain-to-central change occurs as DST ends, the destination (central) time zone is already out of DST at the instant when the transition occurs; things get handled correctly without any special casing (take America/North_Dakota/Center, please.) --ado -----Original Message----- From: Andy Lipscomb [mailto:AndyLipscomb@decosimo.com] Sent: Thursday, January 26, 2006 09:03 To: tz@lecserver.nci.nih.gov Subject: RE: Upcoming Indiana time zone moves + .PP + If, + for a particular zone, + a clock advance caused by the start of daylight saving coincides with + and is equal to a clock retreat caused by a change in UTC offset, .IR + zic produces a single transition to daylight saving at the new UTC + offset (without any change in wall clock time). Can this be implemented also for the opposite case (daylight savings ends, but the offset is advanced)? This was the case with the M->C changes in the Dakotas.