Date: Wed, 3 Aug 2022 12:57:54 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <265e0d1d-9703-81bc-4bcc-ae27ec820be8@cs.ucla.edu> Sorry, I had a period when I didn't read any (or almost any) tz mailing list messages, just left them unread for later. That was particularly messages on this topic which I consider absurd really. Now is later (for some messages anyway) - I hadn't seen this message before. | 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. Not backzone as such - but if it were the same data in the files it belongs in, then sure. And: | In short, patches are welcome (please use git format-patch form). I don't use git, have never used git, and don't plan on ever doing so. So, that is unlikely to happen. On my system: jacaranda$ git clone anything -bash: git: command not found | 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. I have no problem with that as a general philosophy, but I prefer to do it by being inclusive, rather than exclusive - if someone has a reason to want a zone, which meets the guidelines, then create it. Why argue? The proposer would need to supply the data, and some evidence as to its veracity, but if they can do that, what is the problem? Fairly applying the guidelines is important of course. Certainly I have never been a proponent of specifying "one (or at least one) zone per country", rather I prefer "one zone for each authority that defines timezones" - which generally means the same thing in practice, as countries generally consider themselves sovereign, so anything that requires legal definition must be done somewhere in the country - but by avoiding use of the word, we can avoid the "are you a country?" and "who decides" issues. All that we'd require is evidence that there's someone setting the time in some region, which people in the area actually use (eg: Eucla ). Certainly none of the changes that have been made avoid any of the naming issues - the names exist whether just as a link or an actual zone. | Of course we cannot forestall all possible | political complaints; still, it's a win to be as nonpolitical as we | reasonably can. Yes, but you seem to be inventing potential complaints in order to make changes, without there being any real reason to believe that anything is being gained by this. | and the recently-installed tailored_tarballs | target[2] should suffice for Java-like downstream users. As you might have seen from my previous message (reply to a message from Stephen Colebourne) it doesn't do what we need, as we distribute the source (files) as well as TZif - they both need to contain the appropriate data (and users need to be able to simply update from one of the source files - get new versions of the zones it produces, and have the same results, modulo any changes they made, as the distributed versions). In this, also note that we do not use, or distribute, your Makefiles, NetBSD has a fairly rigorous set of Makefiles, which do (in a very minimalist way - making use of common makefile fragments) what is needed, and no more. We also use (and update) the tzcode and tzdata files separately (different maintainers in NetBSD). The data generally gets updated very quickly after it is released, or used to before it started needing manual manipulation - the code less frequently, as it needs to be merged with our changes. | 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. I wouldn't express an opinion on that, as I don't think any of the move to backzone is appropriate - not from the very earliest (except in those very very few cases where the zone should never have existed at all). I'd like to see all the data moved back where it belongs, and not have some of it being treated as first class, and other as no-class-at-all. kre