On Saturday, 25 September 2021 02.58.09 CEST Paul Eggert via tz-announce via tz wrote:
The 2021b release of the tz code and data is available. Thanks, this gives us some time to discuss more calmly now.
[...]
This release is prompted by recent announcements by Jordan and Samoa. It incorporates many other changes that had accumulated since 2021a. However, it omits most proposed changes that merged all Zones agreeing since 1970, as concerns were raised about doing too many of these changes at once.
No, Paul, the issue was never once about the _number_ of changes. There is not a single time anyone asked to reduce the number of changes per release! Either you still totally do not understand all the emails concerning this subject (which would surprise me and be very concerning for the TZ coordinator) or you are deliberately misrepresenting what happened here over the last half year (which I personally find insulting to the community here and does not bode well for a constructive upcoming discussion): I cannot find any request to reduce the number of zone-to-link-changes to any other number than zero in my records. Instead, there were numerous relevant issues with the proposed changes raised, among those were (I might have forgotten some): * Software incompatibilities * Equality issues (not everyone seems to share your view on what is equitable) * Data correctness issues (after the patch users will receive knowingly wrong data for <1970 instead of best-effort data) * Objection on the Zone-Link conversion itself and the request for a discussion on the roles of backdata and the main data base. * Issues with the intransparency on whether a user is using a Link or Zone in various software packages and the consequences thereof. * Loss of information on the quality of the pre1970 data, * The worry of forks and the fragmentation of the user base / compatibility with other software; * issues of a change in behavior for pre-1970 data for a significant number of users also especially for the Android userbase where software updates seem (more than just) difficult. I grant, that some or even most of these issues probably have been prevalent since much older time, but as the link-merging so far mostly affected zones without a contributing, active, numerous, interested, enabled or active user community, the effects probably have not been noticed or raised in this list until recently.
It does keeps some of these changes in the interest of making tzdb more equitable one step at a time; (see above, there seems not even to be consensus on that)
see "Merge more location-based Zones" below.
[...]
Merge more location-based Zones whose timestamps agree since 1970, as pre-1970 timestamps are out of scope. This is part of a process that has been ongoing since 2013. This does not affect post-1970 timestamps, and timezone historians who build with 'make PACKRATDATA=backzone' should see no changes to pre-1970 timestamps. When merging, keep the most-populous location's data, and move data for other locations to 'backzone' with a backward link in 'backward'. For example, move America/Creston data to 'backzone' with a link in 'backward' from America/Phoenix because the two timezones' timestamps agree since 1970; this change affects some pre-1968 timestamps in America/Creston because Creston and Phoenix disagreed before 1968. The affected Zones are Africa/Accra, America/Atikokan, America/Blanc-Sablon, America/Creston, America/Curacao, America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville, and Antarctica/Syowa.
Thanks, at least we now have a good and concise summary on what happened. Cheers, Jürgen -- Jürgen Appel Research Scientist The Danish National Metrology Institute Dansk Fundamental Metrologi, DFM A/S (dfm.dk) Kogle Allé 5 DK-2970 Hørsholm Denmark Mobile: +45 25459049 Email: jap@dfm.dk VAT: DK-29217939 GPG key: http://pgp.mit.edu:11371/pks/lookup?search=J%C3%BCrgen+Appel&op=get