[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