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.