[tz] Add option to act like global-tz

Paul Eggert eggert at cs.ucla.edu
Thu Aug 18 16:33:19 UTC 2022


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*.



More information about the tz mailing list