[tz] [tz-announce] 2021b release of tz code and data available
jap at dfm.dk
Sat Sep 25 16:01:46 UTC 2021
On Saturday, 25 September 2021 02.58.09 CEST Paul Eggert via tz-announce via
> 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
* 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
> 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
Thanks, at least we now have a good and concise summary on what happened.
The Danish National Metrology Institute
Dansk Fundamental Metrologi, DFM A/S (dfm.dk)
Kogle Allé 5
Mobile: +45 25459049
Email: jap at dfm.dk
More information about the tz