[tz] proposal for new tzdb versions

[Jürgen Appel]

Dear Paul Eggert,

On Wednesday, 22 September 2021 20:30:38 CEST Paul Eggert via tz wrote:

> In light of the previous discussions and the fact that we need a new
> release very soon, I propose the following:
> 
> * We release 2021b pretty much as-is (with the usual release
> administrivia such as updating NEWS).
> 
> * We also generate a separate 2021a1 version, which is like 2021a except
> with the Samoa change that is prompting 2021b. This version recognizes
> the concerns about the number of changes to pre-1970 timestamps in
> 2021b. I'll do this by publishing a patch to 2021a, along with a patched
> tarball, on my website at UCLA.

Please at least swap the names of the two releases. In my eyes, there seemed 
to have been a consensus to let the discussion cool down and then find a way 
forward. Pushing controversial changes out in the main line won't help the 
following discussion.

There is no immediate need to push any changes except the Samoa rule changes 
out _right now_, so please incorporate just those into 2021b and let's 
reconcile on how to proceed thereafter.

> Although this is effectively a fork in the short term, the idea is that
> it's a small fork with the intent that we'll work together to combine
> the two approaches in later releases, taking the abovementioned concerns
> into account.


> There is precedent for this approach, in that when there were
> compatibility problems with earlier releases, I generated alternate
> tarballs to support downstream users while they were adapting their
> database readers. Although the two cases are not the same, generating an
> alternate distribution also has the benefit of giving us time.

That's a good idea, although your suggested naming scheme will potentially and 
nunnecessarly cause chaos for all those who did not pay attention to this 
mailing list and just rely on the usual naming format or blindly just consume 
the data.

Especially with the new information in the emails emails stating issues with 
time_zone by name in C++20 and java DateTimeZone.forID, please honestly take 
this into consideration.

>From affected Europe/Copenhagen,
	Jürgen

-- 
Jürgen Appel
Research Scientist, Time & Frequency
Denmark's National Metrology Institute
Dansk Fundamental Metrologi, DFM A/S (dfm.dk)
Kogle Allé 5
DK-2970 Hørsholm
Denmark

Mobile: +45 25459049
Email: jap at dfm.dk
VAT: DK-29217939