Upcoming Indiana time zone moves
My current sense: in the absence of clarification from the United States Department of Transportation (DOT), the way to proceed with the upcoming Indiana time zone moves is to handle them as direct transitions from Eastern Standard Time to Central Daylight Time (without wall clock changes). 1. This reflects what's happened historically in other places. 2. This reflects what I'd expect to happen in reality in Indiana-- folks in the affected areas will not change their clocks. 3. This reflects presumed regulatory intent. Given the peculiar characteristics of the particular second DOT chose for the transition, and the overwhelmingly larger number of seconds in a year, I believe it highly likely that DOT's choice was made with the intent of allowing the transition to occur without clocks changing. Also, there's no mention in the DOT docket of the need for changing clocks twice. I've attached changes to the "zic" manual page that document the reprogramming done back in the year 1996 to do direct transitions; the changes also provide information on how to get (very close to) a one-hour retreat followed one hour later by a one-hour advance. Since the affected regions will spend an hour in a nether-region between CDT and EST, perhaps a special time zone abbreviation is needed. The only letter between C and E is D: "Decidedly Odd Time" (DOT) :-) --ado ------- zic.8 ------- *** /tmp/geta8763 Tue Jan 24 12:03:21 2006 --- /tmp/getb8763 Tue Jan 24 12:03:21 2006 *************** *** 411,424 **** .q Rolling if the leap second time given by the other fields should be interpreted as local wall clock time. ! .SH NOTE For areas with more than two types of local time, you may need to use local standard time in the .B AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. .SH FILE /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.22 --- 411,444 ---- .q Rolling if the leap second time given by the other fields should be interpreted as local wall clock time. ! .SH NOTES For areas with more than two types of local time, you may need to use local standard time in the .B AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. + .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). + If you want two separate transitions + (for example, + a one-hour retreat from + U. S. Eastern Standard Time + to + U. S. Central Standard Time + followed one hour later by a one-hour advance to + U. S. Central Daylight Time), + you can artificially + (and slightly inaccurately) + specify the UTC offset change as occuring a single second too early. .SH FILE /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.23
Arthur David Olson <olsona@elsie.nci.nih.gov> writes:
+ If you want two separate transitions + (for example, + a one-hour retreat from + U. S. Eastern Standard Time + to + U. S. Central Standard Time + followed one hour later by a one-hour advance to + U. S. Central Daylight Time), + you can artificially + (and slightly inaccurately) + specify the UTC offset change as occuring a single second too early.
I found that you can do it without the one-second glitch, by coding the transitions by hand, as follows. Zone Hypothetical -5:00 - EST 2006 Apr 2 7:00u -6:00 - CST 2006 Apr 2 8:00u -6:00 1:00 CDT 2006 Apr 2 9:00u -6:00 US C%sT I couldn't figure out any way to do it with just two transitions, which would be the obvious way to do it. (Nor could I do it with wall clock time; I had to resort to UTC.) Admittedly this is kind of kludgy. I suppose zic could make it easier to shoot yourself in the foot, though surely this is low priority.
I think that the tz database should be containing rules that clearly state which tz transitions will happen, and we should not rely on zic to "mend things". One of the reasons is not to put an extra burden on different applications that read the tz database, and another is to allow people like Deborah Goldsmith and myself to read the rules and actually understand what goes on. If we don't need the "CDT" between 2:00 and 3:00 for the good citizens of Zone Hypothetical, we can just use (1) Zone Hypothetical -5:00 - EST 2006 Apr 2 3:00 -6:00 US C%sT My argument is that these citizens should not go on Central Daylight time before the rest of the world, so they will be on EST until 3:00. However, if we *insist* on having them go on CDT at 2:00 (I still think that this is an overinterpretation of the DOT ruling, but for arguments sake), then we should be able to implement it as (2) Zone Hypothetical -5:00 - EST 2006 Apr 2 2:00 -6:00 1:00 CDT 2006 Apr 2 3:00 -6:00 US C%sT Since I don't have zdump here I can't test this, but it works in my program and my brain. If zic is messing something up here, then I think zic should be changed, because the input is clear (I hope). If (1) is acceptable, we are still avoiding the issue a bit, because the original zone could have used daylight saving too, as an example Zone Hypothetical -5:00 US E%st 2006 Apr 2 2:00 -6:00 US C%sT this won't work unless zic smoothens out the one hour jumps at 1:59:59 EST to 1:00:00 CST and at 1:59:59 CST to 3:00:00 CDT, so if we want it to be explicit, to avoid depending on zic, it should be (3) Zone Hypothetical -5:00 US E%st 2006 Apr 2 2:00 -6:00 1:00 CDT 2006 Apr 2 3:00 -6:00 US C%sT Although the above could not be expressed in 2 lines only, it has a certain elegance because it states "clearly" that something abnormal is going on between 2:00 and 3:00. If we don't let the citizens of Zone Hypothetical go on CDT before the rest of the world, we would still need 3 lines this way (4) Zone Hypothetical -5:00 US E%st 2006 Apr 2 2:00 -5:00 - EST 2006 Apr 2 3:00 -6:00 US C%sT I think this a cleaner approach, (3) or (4), than relying on zic to mend the one-hour hickups. It would impose the need for a complete revision of the tz database to explicitly express these transitions. I would volunteer to find the above fixes to the tz database if there is nobody else that would. When that is in place, we can revert the changes to zic that happened in 1996. Can anybody test (2) on zdump and report it here? Any comments are welcome. Regards, Jesper Nørgaard Welen -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Tuesday, January 24, 2006 18:03 To: tz@lecserver.nci.nih.gov Subject: Re: Upcoming Indiana time zone moves Arthur David Olson <olsona@elsie.nci.nih.gov> writes:
+ If you want two separate transitions + (for example, + a one-hour retreat from + U. S. Eastern Standard Time + to + U. S. Central Standard Time + followed one hour later by a one-hour advance to + U. S. Central Daylight Time), + you can artificially + (and slightly inaccurately) + specify the UTC offset change as occuring a single second too early.
I found that you can do it without the one-second glitch, by coding the transitions by hand, as follows. Zone Hypothetical -5:00 - EST 2006 Apr 2 7:00u -6:00 - CST 2006 Apr 2 8:00u -6:00 1:00 CDT 2006 Apr 2 9:00u -6:00 US C%sT I couldn't figure out any way to do it with just two transitions, which would be the obvious way to do it. (Nor could I do it with wall clock time; I had to resort to UTC.) Admittedly this is kind of kludgy. I suppose zic could make it easier to shoot yourself in the foot, though surely this is low priority.
Jesper Norgaard Welen <jnorgard@prodigy.net.mx> writes:
Zone Hypothetical -5:00 US E%st 2006 Apr 2 2:00 -6:00 1:00 CDT 2006 Apr 2 3:00 -6:00 US C%sT
Yes, that is the sort of thing that zic used to require, but it was error-prone to require two zic transitions for one "real-world" transition in many common cases, and this caused multiple errors in the tz database. I agree that what zic does now is a bit confusing, but what zic used to require was even more confusing in practice. If any change is to be made here, I'd prefer to change to something that is better.
participants (3)
-
Arthur David Olson -
Jesper Norgaard Welen -
Paul Eggert