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(a)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.
