On Sat, 5 Jun 2021 at 04:14, Paul Eggert via tz <tz@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