Yeah, so far I don't see any justification in here for creating this short term fork — a reorganization of the historical data does not exactly seem to be something that is important in the short term and the cost will be quite high.

I'll also note that the proposed version 2021a1 is likely going to cause problems all by itself. In the Downloading the tz database section of tz-link it says:

Since 1996, each version has been a four-digit year followed by lower-case letter (a through z, then za through zz, then zza through zzz, and so on). Since version 2016h, each release has contained a text file named "version" whose first (and currently only) line is the version.

This is not exactly a guarantee, but 2021a1 does violate that nomenclature, which will likely break scripts that rely on it (I have scripts that actively assert that the version numbering follows this convention, for example).

I have personally been in the camp of giving Paul the strong benefit of the doubt on many of these concerns, but I do think it would buy a lot of good will to simply cut a release for 2021a + Samoan changes and call that 2021b and forestall releasing the controversial changes until resolution is reached (ideally with lots of notice, so people have time to update their assumptions about the stability of historical data as distributed).

Best,
Paul

On 9/22/21 15:06, Howard Hinnant via tz wrote:

On Sep 22, 2021, at 2:30 PM, Paul Eggert via tz <tz@iana.org> wrote:

Although this is effectively a fork in the short term,

A fork is a big cost.  What is the benefit that outweighs this cost?

Howard