On 8/17/22 20:30, Bradley White wrote:
The sense I'm getting from discussions on the backzone issue is that many corporations and redistributors will become "PACKRAT"s when moving to 2022b, if only to provide historical consistency
I'm not getting the same sense. And if "historical consistency" means "don't mess with TZDB data", then redistributors should avoid the PACKRAT* options, as switching from 2022a to 2022b+PACKRATDATA introduces more changes to timestamps than simply upgrading from 2022a to 2022b. There are other good reasons not to use the PACKRAT* options. Not only do they add politics (which in the long run will likely cause trouble for people opting for PACKRAT*), they use lower-quality data that, despite repeated requests, nobody has volunteered to maintain. If you want stability this is not a good basis for it.
Concretely, I suggest that backzone changes affecting current timestamps (like the Africa/Freetown case above) be treated with the same release expediency that would be afforded to similar changes in the "default" data.
I don't see a need to issue a new TZDB release merely because of glitches involving the new options. Those who are competent and brave (or foolhardy :-) enough to use these bleeding-edge options can easily apply the patch published in <https://mm.icann.org/pipermail/tz/2022-August/031836.html>, assuming they care about the glitches. The rest of us can wait for the next release. As usual, though, my bottom-line advice is: don't use PACKRAT*.