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.