I agree with Tom's comments. We really don't want the disruption that would happen when some people pick up the 2021b and others pick up 2021a1; especially when it is likely that many of the people picking up 2021b won't know that they could be breaking downstream clients.

There is *no* harm at all to just issuing a 2021b that has 2021a + Somoan fix right now (no other changes). That is the simple option for now. Then people have the opportunity to hash out the situation without disruption.

Mark

On Wed, Sep 22, 2021 at 11:44 AM Tom Lane via tz <tz@iana.org> wrote:

Paul Eggert via tz <tz@iana.org> writes:
> 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.

"2021a1" is what a number of people would likely have done unofficially,
so making it at least partially official would be better than no action
at all. However, it still seems to me that this course of action is
prejudging the eventual outcome. tzdb distributors who have not been
paying close attention will almost certainly ship 2021b, and then we
will have exactly the data instability that some of us hoped to avoid,
and basically no way to correct that without creating even more
instability.

In short: this is better than shipping 2021b only, but not by much,
because it utterly fails to account for the concerns I have.

regards, tom lane