[tz] Moving more zones to 'backzone'

[Paul Eggert]

On 7/8/22 13:14, Robert Elz wrote:

> If the real reason for this is the workload of dealing with more zones,
> then simply acquire more helpers

Would you like to be a helper? I'd be happy to delegate the job of 
maintaining 'backzone' data.

Also, I'm open to improving 'zic' to make maintenance easier. For 
example, several people have proposed making it easy for Zone X to say 
"I'm like Zone Y from 1920 through 1965", and if done right that would 
be a real win - though writing the code for this would likely not be 
trivial, and we could use it only in vanguard form for a while.

In short, patches are welcome (please use git format-patch form).


Getting back to your comment, technical workload is not the main reason 
to move data to 'backzone'. Politics are more important. For political 
reasons many people care about data that are practically insignificant, 
and these political concerns are a major long-term hazard to this 
project. We're better off heading off these potential disputes at the 
pass, by maintaining the database via nonpolitical guidelines and being 
consistent about that, even if nobody has yet complained politically 
about a particular data item. Of course we cannot forestall all possible 
political complaints; still, it's a win to be as nonpolitical as we 
reasonably can.

 From my point of view, the disagreement that caused the fork was a 
tempest in a rather small teapot, as it has almost no practical 
consequences for TZDB. Users by and large simply don't care about minor 
discrepancies in pre-1970 timestamps. And the few users who do care 
(mostly astrologers) are so ill-served by the completely inadequate data 
in 'backzone' that its presence or absence doesn't matter all that much 
to them either.

Although nobody is happy about the fork, the difference between the two 
variants is so small that it's not worth worrying about from the vast 
majority of users. TZDB already has options that have way bigger 
consequences, such as the options to remove all pre-1970 data, or to add 
leap seconds, or to incorporate even more data from 'backzone'; so it 
should be OK for TZDB to have this new option too. For this reason, I 
wrote, circulated[1] and today installed patches to let TZDB optionally 
emulate global-tz exactly, in the sense that the two approaches generate 
identical TZif files; and the recently-installed tailored_tarballs 
target[2] should suffice for Java-like downstream users.


In reading through the comments on this thread, nobody expressed an 
opinion on the idea of finishing the move to 'backzone' now instead of 
doing it in dribs and drabs. So I finished the move now by installing 
the attached patches into the development version on GitHub as there 
seemed to be no benefit to delaying this further, given the recently 
added installation options.

The first of these two patches was circulated about a month ago[3]; the 
second finishes the job of moving to 'backzone' the location-based zones 
that are redundant since 1970.

In the default build, these two patches affect only pre-1970 timestamps. 
With the new 'make PACKRATDATA=backzone PACKRATLIST=zone.tab' option, 
these two patches don't affect any timestamps and the result generates 
TZif files identical to those generated by global-tz.


[1] https://mm.icann.org/pipermail/tz/2022-July/031717.html
[2] https://mm.icann.org/pipermail/tz/2022-July/031710.html
[3] https://mm.icann.org/pipermail/tz/2022-July/031631.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Move-nine-more-zones-to-backzone.patch
Type: text/x-patch
Size: 40769 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20220803/cfe1de30/0001-Move-nine-more-zones-to-backzone-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Finish-duplicate-since-1970-moves.patch
Type: text/x-patch
Size: 33317 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20220803/cfe1de30/0002-Finish-duplicate-since-1970-moves-0001.patch>