2023d zdump with "min" year rule?
Dear TZ Database maintainers, We (Unicode ICU project) preserve time zones deprecated in the TZ database. We keep old systemv file and include these zones in our library. For example, # SystemV time zones. # IANA tzdb file 'systemv' file has these SystemV/* zones commented out up to 2020a. # 'systemv' file was removed in 2020b. We keep them in this supplemental zone data # file for compatibility purpose. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D Rule SystemV min 1973 - Oct lastSun 2:00 0 S Rule SystemV 1974 only - Jan 6 2:00 1:00 D Rule SystemV 1974 only - Nov lastSun 2:00 0 S Rule SystemV 1975 only - Feb 23 2:00 1:00 D Rule SystemV 1975 only - Oct lastSun 2:00 0 S Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D Rule SystemV 1976 max - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone SystemV/AST4ADT -4:00 SystemV A%sT Zone SystemV/EST5EDT -5:00 SystemV E%sT Zone SystemV/CST6CDT -6:00 SystemV C%sT Zone SystemV/MST7MDT -7:00 SystemV M%sT Zone SystemV/PST8PDT -8:00 SystemV P%sT Zone SystemV/YST9YDT -9:00 SystemV Y%sT Zone SystemV/AST4 -4:00 - AST Zone SystemV/EST5 -5:00 - EST Zone SystemV/CST6 -6:00 - CST Zone SystemV/MST7 -7:00 - MST Zone SystemV/PST8 -8:00 - PST Zone SystemV/YST9 -9:00 - YST Zone SystemV/HST10 -10:00 - HST ICU data build feeds the extra zone file including above to zic, then run zdump to emit zone offset transitions. Then compare the output with the equivalent output produced by ICU library code. I’m currently working on TZ database 2023d and found this check is failing for SystemV/* with daylight saving time rule. All other zones work fine. With zdump in 2023d, all transitions before 1970 are not reported. For example: $ zdump -c 1900,1975 -V SystemV/AST4ADT emits the output below: SystemV/AST4ADT Sun Apr 26 05:59:59 1970 UT = Sun Apr 26 01:59:59 1970 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 26 06:00:00 1970 UT = Sun Apr 26 03:00:00 1970 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 25 04:59:59 1970 UT = Sun Oct 25 01:59:59 1970 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 25 05:00:00 1970 UT = Sun Oct 25 01:00:00 1970 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 25 05:59:59 1971 UT = Sun Apr 25 01:59:59 1971 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 25 06:00:00 1971 UT = Sun Apr 25 03:00:00 1971 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 31 04:59:59 1971 UT = Sun Oct 31 01:59:59 1971 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 31 05:00:00 1971 UT = Sun Oct 31 01:00:00 1971 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 30 05:59:59 1972 UT = Sun Apr 30 01:59:59 1972 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 30 06:00:00 1972 UT = Sun Apr 30 03:00:00 1972 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 29 04:59:59 1972 UT = Sun Oct 29 01:59:59 1972 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 29 05:00:00 1972 UT = Sun Oct 29 01:00:00 1972 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 29 05:59:59 1973 UT = Sun Apr 29 01:59:59 1973 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 29 06:00:00 1973 UT = Sun Apr 29 03:00:00 1973 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 28 04:59:59 1973 UT = Sun Oct 28 01:59:59 1973 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 28 05:00:00 1973 UT = Sun Oct 28 01:00:00 1973 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Jan 6 05:59:59 1974 UT = Sun Jan 6 01:59:59 1974 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Jan 6 06:00:00 1974 UT = Sun Jan 6 03:00:00 1974 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Nov 24 04:59:59 1974 UT = Sun Nov 24 01:59:59 1974 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Nov 24 05:00:00 1974 UT = Sun Nov 24 01:00:00 1974 AST isdst=0 gmtoff=-14400 This is not a problem with 2023c. 2023c emits transitions starting year 1900 (the first year in the range) to 1975. I think these are only zones using rule line with “min” year rule. I suspect there is a regression bug in zdump when such rule is used. -Yoshito Umaoka
On 2024-01-03 14:37, Yoshito Umaoka via tz wrote:
I think these are only zones using rule line with “min” year rule. I suspect there is a regression bug in zdump when such rule is used.
Thanks, good catch. It's actually the other way around, though: 2023c zdump is buggy, and 2023d zdump is fixed. There's a longer story here. I assume that the TZif file in question is the attached binary file AST4ADT. This is what I get by running 'zic' on your input, and I get the same thing regardless of whether I use 2023c zic or 2023d zic This AST4ADT file contains a default time type of AST (-04, no DST) and explicit transitions to and from ADT (-03, DST). The first explicit transition is to DST at 1970-04-26 06:00:00 UTC. The last explicit transition is at 1976-04-25 06:00:00 UTC; after that, the TZ string "AST4ADT,M4.5.0,M10.5.0" applies. Hence there are no transitions before 1970-04-26 06:00:00 UTC. For this TZif file, 2023c zdump incorrectly reports many transitions before 1970. This is due to a bug in 2023c localtime.c that was fixed in 2023d. The bug causes localtime to incorrectly infer that the 400-year timestamp sequence after 1970 is repeated before 1970. Superficially, one might think that 2023c zdump is doing the right thing, because the .zi file says this: Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D Rule SystemV min 1973 - Oct lastSun 2:00 0 S and it looks like 2023c zdump is using those rules for all timestamps before 1973. But it's not doing that. It's using these rules only for timestamps in the years ..., 1170 through 1173, 1570 through 1573, 1970 through 1973, 2370 through 2373, 2770 through 2773,.... You can see that the bug is present by looking at timestamps for years like 1574 and 2374, which do not use the abovementioned rules because they echo the oddball rules of 1974. The longer story here is that the "min" columns in those rule lines cannot be implemented in TZif files. The TZif format formerly supported those lines when it was 32-bit only, but the 64-bit format (which is all that anybody should use now) doesn't work with the "min" lines because there is no way to express daylight-saving rules indefinitely into the past. 'zic -b slim' fudges this by supporting time stamps after 1970 or after 1900 (depending on other options) when you use "min", and this is good enough for most practical uses. However, apparently your test cases are testing timestamps before 1970 and are running into this issue. TZDB removed the systemv file in version 2020b, so we don't need to worry about this issue for TZDB itself. TZDB's systemv file was present only to mimic the hardwired AT&T System V (1983) DST rules, which are wrong for many US timestamps before 1967 or after 1986. It was a good thing that we commented its Zones out in release 2001a and removed the systemv file entirely in release 2020b, as this stuff was causing more confusion than it cured - and this email is evidence of further confusion yet. For ICU, if you want to keep the systemv names with their original meanings in AT&T System V, you can do something like the following: # Implement the time zone conversions of AT&T System V (1983). # This data should not be used by applications, # as it does not correspond to what clocks did in the real world. # It is present only for compatibility with broken systems. Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D Rule SystemV min 1973 - Oct lastSun 2:00 0 S Rule SystemV 1974 only - Jan 6 2:00 1:00 D Rule SystemV 1974 only - Nov lastSun 2:00 0 S Rule SystemV 1975 only - Feb 23 2:00 1:00 D Rule SystemV 1975 only - Oct lastSun 2:00 0 S Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D Rule SystemV 1976 max - Oct lastSun 2:00 0 S Zone SystemV/AST4ADT 0 - -00 1901 Dec 13 20:45:52u -4:00 SystemV A%sT 2038 Jan 19 03:14:08u 0 - -00 Zone SystemV/EST5EDT 0 - -00 1901 Dec 13 20:45:52u -5:00 SystemV E%sT 2038 Jan 19 03:14:08u 0 - -00 Zone SystemV/CST6CDT 0 - -00 1901 Dec 13 20:45:52u -6:00 SystemV C%sT 2038 Jan 19 03:14:08u 0 - -00 Zone SystemV/MST7MDT 0 - -00 1901 Dec 13 20:45:52u -7:00 SystemV M%sT 2038 Jan 19 03:14:08u 0 - -00 Zone SystemV/PST8PDT 0 - -00 1901 Dec 13 20:45:52u -8:00 SystemV P%sT 2038 Jan 19 03:14:08u 0 - -00 Zone SystemV/YST9YDT 0 - -00 1901 Dec 13 20:45:52u -9:00 SystemV Y%sT 2038 Jan 19 03:14:08u 0 - -00 Zone SystemV/AST4 -4:00 - AST Zone SystemV/EST5 -5:00 - EST Zone SystemV/CST6 -6:00 - CST Zone SystemV/MST7 -7:00 - MST Zone SystemV/PST8 -8:00 - PST Zone SystemV/YST9 -9:00 - YST Zone SystemV/HST10 -10:00 - HST Given the confusion discussed above, it seems like a good idea for zic to diagnose troublesome usages such as the ones you mentioned, and to substitute sane values instead. I did that by installing the attached proposed patches into the development repository. Patch 0002 is the important one; the others are minor refactoring/documentation.
Thanks Paul. I also thought “min” year might not work practically with 64bit format. As you suggested, I will enforce the rule only used for 32bit time range (1902-) for SystemV zones for compatibility for meanwhile. We also consider completely dropping SystemV zones. -Yoshito
participants (2)
-
Paul Eggert -
Yoshito Umaoka