[tz] Undoing the effect of the new alike-since-1970 patch

[Stephen Colebourne]

On Sat, 5 Jun 2021 at 04:14, Paul Eggert via tz <tz at iana.org> wrote:
> So I propose we add a Makefile or similar build-time option to let tzdb
> users have it either way. Set the flag one way, and it will be as if the
> recently-proposed changes did not occur. Set it the other way, and
> you'll get the changes.

Unfortunately, this approach doesn't work for the downstream users I
represent unless the default data in tzdb is as it was before the
patch. This is because the downstream users consume the source code
files without using the makefile. As has been discussed previously,
this is a common way that tzdb is consumed, making the default data
critical. And as discussed previously, there are a large number of
independent users consuming the data who would not all know about the
need for change.

I have no problem with an option in the makefile that automatically
merges zones where they are the same after 1970, but by default the
data needs to be present in the source file as it was previously. My
view is that the need for a more compact tzdb output is likely to be
limited to space-constrained devices whose developers are more likely
to be aware of such a flag.

> This will be similar to our vanguard/rearguard support, which helped
> address a similar disagreement back in 2018.

It is important to understand that rearguard did not solve the problem
in 2018. Downstream projects were still forced to change their code.
Joda-Time has explicit (and flaky) code in place to revert the 2018
changes as it reads in the source files. This is because Joda-Time
users do not use the makefile, so there is no direct way to access the
rearguard data.

> On the other hand there are also fairness and
> guideline-oriented reasons for the patch

FWIW, I entirely agree that it is wrong that there is a zone with full
history for Norway and Sweden but not for Angola or Slovakia. The
difference is that I think TZDB should be expanded to include the
missing history, not shrunk.

Given the above, I think the right course of action is to revert the
change first, and then work on agreeing what the target state of TZDB
should be (which deserves a separate thread).

Stephen