"Murray S. Kucherawy via tz" <tz@iana.org> writes:
My understanding is that these data are being moved from the regional files to the backzone file. It's been pointed out before that a compile-time option can be set to include those entries in the production output of the build.
Correct.
If that's wrong or incomplete, please do correct me. In either case, can you please explain why that compile-time option is not an acceptable solution for those who object to the change?
There are two core difficulties from my perspective: 1. It's not possible to separate the new backzone zones from the old. It's therefore impossible to generate a TZif tree that matches the prior dataset: you can either lose the data for the moved zones, or gain it back while also absorbing a whole lot of other changes of dubious quality. (If they weren't dubious, they wouldn't have been in backzone to begin with.) Either choice forces dubious changes to one or another subset of the zones. We know for certain that not including backzone will degrade the data for the moved zones. It's less clear how damaging adding backzone will be to the overall quality of the data set, but presumably if people felt really good about those entries, they'd have been in the main data set. 2. This approach puts it on individual tzdb distributors to decide which of these two options to choose. Some will choose differently than others, meaning we'll now have two received versions of tzdb, which is as bad as a fork from the perspective of end users. (It was argued that we already have problem #2 because some distributors already use backzone. AFAICT that's only a small minority though. It'd likely become a much bigger issue.) regards, tom lane