Regarding use of "24:00" in data files (which pre-1998 versions of zic can't handle), Martin Smoot wrote:
I would think at some point that we would have to give up on maintaining compatibility with these older versions of zic. after all it has been several years. how many people do not have a compiler to rebuild zic?
Visiting this whole 24:00 business didn't happen because of Kiefer Sutherland/Jack Bauer; we did get a report of difficulty from a user trying to pump updated data files through a vendor-supplied zic. If use of 24:00 was in support of some active time zone, we'd have no choice but to abandon efforts at compatibility, but when the use of 24:00 is only to support a limited number of historic transitions in a limited number of places, there's more motive to avoid use of 24:00 (and thus to avoid problems for folks trying to use the data with existing compilers). We do, of course, want to keep the code in place so that people for whom it would be useful can benefit from it. We face more latency in our work with the time zone stuff than do vendors such as Sun with other software. Sun has to implement and distribute changes and give customers time to adopt them before abandoning support. We have to implement and distribute changes, wait for vendors to implement and distribute them, and then wait for customers to adopt them. So our "give up on maintaining compatibility" time frame is, of necessity, longer than folks might be accustomed to. A complicating factor is that the time zone data files do now get processed by alternate readers that aren't part of the time zone package. At this point we've got the "this is a simpler way to do it" comments in the relevant place in the data file. The next step will be to uncomment that stuff and comment out the more complicated (but more generally useable) stuff. I don't know what the best time frame is for doing that; I imagine it's best to do it before the retirement of yours truly (now 8-1/2 years off). ---------------------------------------------- Another piece of fallout from the 24:00 work was the discovery that back during the Great Depression Toronto was making switches at 2:00 a.m. on the first Sunday after the last Saturday in April and September--even if this meant that the switch got pushed back to May or October. Now as currently set up, when zic is asked to make a switch on a day of the month such as... Sun>=25 ...it checks to ensure that there is indeed such a Sunday in the month and fails if there isn't one. I believe it's reasonable to lift this restriction; doing so allows simpler expression of rules covering situations such as those in Toronto, as witness the (regression-tested) changes attached below. As always, the point of the exercise is not so much to deal with what happened in Toronto way back when, but to be prepared to deal with the situation if some wild-eyed legislators decide to adopt such a scheme in the future. --ado ------- zic.c ------- *** /tmp/geta11385 Mon Dec 22 12:35:17 2003 --- /tmp/getb11385 Mon Dec 22 12:35:18 2003 *************** *** 2138,2144 **** wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0 || i >= len_months[isleap(y)][m]) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } --- 2138,2144 ---- wday = LDAYSPERWEEK - 1; --i; } ! if (i < 0) { error(_("no day in month matches rule")); (void) exit(EXIT_FAILURE); } ------- northamerica ------- *** /tmp/geta11403 Mon Dec 22 12:35:18 2003 --- /tmp/getb11403 Mon Dec 22 12:35:18 2003 *************** *** 989,1000 **** # Shanks says 1923-09-19; assume it's a typo and that "-16" was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D ! Rule Toronto 1927 1932 - Sep lastSun 2:00 0 S ! Rule Toronto 1928 1931 - Apr lastSun 2:00 1:00 D ! Rule Toronto 1932 only - May 1 2:00 1:00 D ! Rule Toronto 1933 1940 - Apr lastSun 2:00 1:00 D ! Rule Toronto 1933 only - Oct 1 2:00 0 S ! Rule Toronto 1934 1939 - Sep lastSun 2:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D --- 989,998 ---- # Shanks says 1923-09-19; assume it's a typo and that "-16" was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D ! Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S ! Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D ! Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S ! Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D
If it would be wrong to leave the 24:00 stuff in the data files, for reasons of compatibility with old systems (even though zic has been able to handle that for years), it would certainly be wrong to start inserting Sun >= 25, at the zone time that zic is modified to be able to handle it. I have no problem with the mod to zic, though it should also handle Sun <= 3 in an analogous way for completeness - but the zone files should simply have the explicit dates listed for those old transitions which would like to use this modification (the few that were wrong the old way). kre
participants (2)
-
Olson, Arthur David (NIH/NCI) -
Robert Elz