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