TZif Version Selection Issue in tzcode2025b
Hi All, We have encountered an issue after upgrading to tzcode2025b, where zoneinfo files that were previously generated in TZif3 format are now being generated in TZif2 format. This change appears to be due to the removal of the forced version in the writezone() call in zic.c file. Upon investigation, we found that: ->The logic in stringrule() that sets compat = 2013 based on wdayoff is not meaningful in practice. ->For rules like Sun>=8, wdayoff = 0, so compat = 0, and the compiler now generates TZif2. ->This behavior change appears to result from the removal of the forced version and the introduction of dynamic version selection logic. For example, in the northamerica file, we have: Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S These rules are used by zones such as America/Chicago and others. Since Sun>=8 results in wdayoff = 0, the compat value remains 0, and the compiler now generates TZif2 instead of TZif3. This change affects all zones relying on similar rules, even though the rule definitions themselves have not changed. Specifically, the change from: writezone(zpfirst->z_name, envvar, ZIC_VERSION); // older code to: writezone(zpfirst->z_name, envvar, version, defaulttype); // new code has caused the compiler to emit TZif2 for rules that previously resulted in TZif3. We believe this logic does not reliably reflect the need for TZif3 and may lead to inconsistent or unexpected output formats. We would appreciate your thoughts on this and whether a patch or enhancement is planned to address it. Best Regards, Jeelan
On 2025-05-30 12:06, PATAN JEELAN BASHA via tz wrote:
For example, in the northamerica file, we have:
Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S
These rules are used by zones such as America/Chicago and others. Since Sun>=8 results in wdayoff = 0, the compat value remains 0, and the compiler now generates TZif2 instead of TZif3.
This change affects all zones relying on similar rules, even though the rule definitions themselves have not changed.
Specifically, the change from:
writezone(zpfirst->z_name, envvar, ZIC_VERSION); // older code to: writezone(zpfirst->z_name, envvar, version, defaulttype); // new code
has caused the compiler to emit TZif2 for rules that previously resulted in TZif3.
That change in TZDB 2018f was due to this patch: https://github.com/eggert/tz/commit/83c119f4d5d48ba37d73e42b0f12da3ae06b6c3f which reverted this part of zic's behavior back to that of TZDB 2013c. However, I'm not observing the behavior that you see. Regardless of whether I build from TZDB 2013c, 2013d, 2018e, 2018f, or 2025b, America/Chicago always uses TZif2 format. Can you isolate the issue down to a small file that can be given as input to zic, and for which an older zic version generates TZif3 but for which 2025b zic generates TZif2? Also, please specify which old zic version you're using. Thanks.
Hi Paul Eggert, Thanks for the clarification. Yes, I also see TZif2 being used consistently across all the versions, including 2013c through 2025b. Just one quick question—since TZif3 is available and is a newer format and technically a higher version than TZif2. is there a specific reason why the IANA time zone database continues to use TZif2? Best Regards, Jeelan
On Wed, 11 Jun 2025 at 13:57, PATAN JEELAN BASHA via tz <tz@iana.org> wrote:
Just one quick question—since TZif3 is available and is a newer format and technically a higher version than TZif2. is there a specific reason why the IANA time zone database continues to use TZif2?
Per tzfile.5, which describes the file format, under "Interoperability considerations": "Other than version 1, writers should generate the lowest version number needed by a file's data. For example, a writer should generate a version 4 file only if its leap second table either expires or is truncated at the start. Likewise, a writer not generating a version 4 file should generate a version 3 file only if TZ string extensions are necessary to accurately model transition times." In short, this is done intentionally to maximize backwards compatibility. -- Tim Parenti
participants (3)
-
PATAN JEELAN BASHA -
Paul Eggert -
Tim Parenti