On 2021-09-20 20:56, Stephen Colebourne via tz wrote:
I have always wanted the first option - forking is not a good outcome.
I propose not to fork tzdb and instead revoke the proposed changes until we can agree on a *complete* picture of how the changes can be effected without inducing undue burdens on any downstream user. Fixing singular aspects of the proposed change does not seem to suffice in this situation. We know one possible solution, proposed by Stephen Colebourne (but others might be worth considering as well): ∙ the main line data of tzdb should contain all the historical data we have, and SHOULD be maintained as such; ∙ there are options to reduce the amount of historical data by merging timezones with links and/or by stripping old transitions from timezone data; such options MAY be added if necessary; ∙ using zic with the same options on successive versions of tzdb data SHOULD not lead to major changes in the scope and structure of the TZif results; ∙ similarly, for those using the tzdb data directly, the organization of tzdb data into files SHOULD not change significantly across successive versions. For instance, the proposed merge of timezones agreeing since 1970 can be done quite simply with a new file with links (such as merge1970) without affecting users who cannot use the merge. Michael Deckers.