[tz] Proposal: Sections for different kinds of backward links

[Stephen Colebourne]

On Fri, 12 Nov 2021 at 05:04, Paul Eggert <eggert at cs.ucla.edu> wrote:

Unfortunately, from my perspective your groupings have eliminated
useful information I need as a downstream consumer.

The category `posixish` is fine.

The distinction between `obsolescent` and `other` seems unnecessary -
they are all IDs no longer suitable for use.

The inability to identify spelling changes is a big problem. As a
downstream consumer I need to be able to indicate which spelling users
should use. I think this needs a separate category. It does require
tzdb to pick which of the spellings is the preferred one, but tzdb
already does this when the Link is defined (In `primary` the
information can be derived from whether it is a Link or Zone, but it
cannot be derived for other categories).

The `primary` category is fine as it is factual (based on clocks
aligning post-1970). To be useful it would need one ID per region (ie.
only one spelling allowed).

Including all non-primary IDs in `secondary` is not helpful at all.
While you may not think that one ID per ISO code is useful, it is
surely clear at this point that others do. What you have here is an
opportunity to provide some relief for those who want one ID per ISO
code without it significantly impacting your maintenance cost. This
would require `secondary` to be split, one listing the main ID per ISO
code (where not in the `primary`) and one listing all the other excess
locations. These categories could be called `secondary` and
`tertiary`.

The net result is that `primary` would represent those IDs you believe
tzdb should provide, while `primary` and `secondary` combined
represent those IDs I believe should be provided (and what was
effectively provided prior to 2014). Were this to be done, it would be
possible to provide a command line option that pulls the relevant
parts of `backzone` in based on the combined list of `primary` and
`secondary`.

As a downstream consumer I'd personally prefer one file with a column
for the type of ID. Having these as separate files makes this more
complex to use (and more complex to maintain IMO).

thanks
Stephen