[tz] 2023d zdump with "min" year rule?

Paul Eggert eggert at cs.ucla.edu
Fri Jan 5 02:55:18 UTC 2024


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AST4ADT
Type: application/octet-stream
Size: 256 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20240104/1588d08a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Name-two-constants-in-zic.c.patch
Type: text/x-patch
Size: 1589 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20240104/1588d08a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Remove-support-for-min-in-Rule-lines.patch
Type: text/x-patch
Size: 6405 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20240104/1588d08a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-NEWS-Fix-America-Ciudad_Juarez-summary.patch
Type: text/x-patch
Size: 924 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20240104/1588d08a/attachment-0002.bin>


More information about the tz mailing list