Hi, Thank you for the earlier discussion and guidance.
I would like to clarify my current thinking and ask specifically about the feasibility of a possible approach. 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. Concretely, 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. - If loading fails catastrophically (e.g., assertion failures or aborts that would later be triggered by zdump or runtime loaders), zic could report an error or warning and avoid installing the file. 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. >From an engineering perspective, this would act as a sanity check using existing code paths, rather than introducing new semantic validation rules. My questions are therefore: - Would reusing zdump-style loading logic inside zic as an optional or internal post-generation check be acceptable from the tzdata design perspective? - Are there architectural, portability, or policy reasons why zic should not invoke such runtime loading logic, even in a limited and optional way? - If this approach is not appropriate, is the preferred expectation that downstream users run tools like zdump separately to detect such failures? I would appreciate any guidance on whether this direction makes sense before exploring a concrete implementation. Best regards, Chunhui Ren
