[tz] Preparing to fork tzdb

[Michael H Deckers]

    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.