On Fri, 12 Nov 2021 at 05:04, Paul Eggert <eggert@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