[tz] Moving more zones to 'backzone'

[Robert Elz]

    Date:        Wed, 3 Aug 2022 12:57:54 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <265e0d1d-9703-81bc-4bcc-ae27ec820be8 at 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