[tz] Preparing to fork tzdb
Michael H Deckers
michael.h.deckers at googlemail.com
Mon Sep 20 21:20:00 UTC 2021
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
∙ 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.
More information about the tz