On 2025-12-16 18:45, renchunhui2025--- via tz wrote:
Rather than treating zdump as a separate “strict validator” while keeping zic intentionally permissive, my idea is to explore whether zic itself could optionally reuse the same tzfile loading path that zdump uses, purely as a post-generation sanity check.
There would be licensing issues, as zic.c is public domain whereas glibc tzfile.c is distributed under the GNU Lesser General Public License.
the idea would be: - zic generates a tzfile as it does today. - Immediately after generation, zic invokes the same internal loading logic used by zdump (e.g., tzset/localtime paths) on that file.
This internal loading logic is different in each OS, and we sometimes lack access to the source code (even aside from licensing issues), so doing this well would be a tricky business.
The motivation here is not to make zic stricter in terms of rule semantics, nor to add rule-specific validation (such as DST-only checks), but simply to catch tzfiles that are internally inconsistent enough to cause runtime aborts when loaded.
Simpler, I think, would be for whatever procedure that runs zic, to run zdump afterwards. This avoids the licensing issues, and no change to zic's or zdump's source code or build procedure is needed. It would be helpful to test zic's output with other TZif readers as well; please see <https://data.iana.org/time-zones/tz-link.html#TZif> for a list.
TZDB already does this sort of thing when you run commands like 'make check', which uses the main TZDB data to test zdump on zic's output.
I hope these comments help, and thanks for the test case and questions.
