[tz] Classifying IDs

[Stephen Colebourne]

Following on from the previous thread [1] I wanted to try and classify
the IDs we have, which may or may not identify missing IDs.

Again, please avoid talking about pre-1970 data at this point.


Obsolete
------------
IDs that are obsolete and should never be used. They date from many
years ago whe tzdb was just starting. Yet these still do appear in
downstream UIs even today (of course UIs should not use the tzdb ID
list, but in reality lots do).

Examples: Portugal, NZ-CHAT, Navajo, Libya.

Proposal: Provide 3-6 months notice, then move obsolete IDs to a new
file "obsolete" which downstream projects are strongly encouraged not
to include. (I would argue that the time has come to properly remove
these IDs, which are very inconsistent in terms of which are provided
and which not, eg Portugal, but not Spain)


Deprecated, same location
------------------------------------
IDs that have been deprecated with a single clear alternative ID being
provided. Both IDs represent the same physical location/city.

Spelling changes: Asia/Katmandu (replaced by Asia/Kathmandu),
Asia/Rangoon (replaced by Asia/Yangon)

ID structure changes: America/Louisville (replaced by
America/Kentucky/Louisville)

Proposal: Ensure all of these are in `backward`
Consider: Is there any way to move these IDs to the obsolete file?
Maybe after 5 years? Or do we just accept backwards compatibility
restrictions on these?


Legally described mega-zones
-----------------------------------------
IDs for locations where a federal or supra-national body defines
rules, eg the EU or US DOT.

Examples: US/Mountain, CET, WET

Consider: Can we write down a rule to identify when something like
this should be included? Then move the matching IDs to the main files
(eg. are the EU and US DOT the only two examples here?)


Regions
-----------
IDs for abstract regions that have had the same wall clock since 1970.

Examples: Europe/Berlin, America/New_York, Africa/Abidjan

Proposal: Ensure all of these are in the main files.
Consider: Should there be new IDs for each of these abstract regions
to indicate they are a separate and distinct concept? eg.
"Region/Berlin". (Maybe something to consider in future threads as it
isn't clear what the benefit of doing so is without considering
pre-1970 which I'm still trying to avoid)


Non-region locations
---------------------------
IDs for locations that are not region IDs. Each ID will have the same
wall clock since 1970 as one of the region IDs.

Examples: Europe/Oslo, Europe/Amsterdam, Atlantic/Reykjavik

Consider: Can we write down a rule that covers which IDs are included
here? And therefore when a new ID can be added to this set? If we can
define a rule, then these can be split so rule-following IDs are in
the main files and rule-breaking ones are in `backward` (although
ideally they should be separate from the spelling changes). Obviously,
we can say these IDs only exist for backwards compatibility, but that
seems like a weak justification, and doesn't tackle the issue of when
a new ID would be added to the list (which has been a point of
tension).

As is well known, I think the obvious rule is that the IDs follow the
ISO-3166-1 standard (rule: one ID per ISO code, additional IDs may be
added where clocks have diverged since 1970). Using ISO-3166 can be
justified by IANA domain policy [2]:
"We are not in the business of deciding what is and what is not a
country. Instead, we employ a neutral standard maintained by the ISO
3166 Maintenance Agency. Our policy is to create new country-code
top-level domains when the country or territory is listed on the ISO
3166-1 standard."

As per the previous thread, these non-region location IDs are actively
used in downstream business applications, and it is not OK that only
works because tzdb happens to have IDs for backwards compatibility.
There needs to be a better justification than that - these non-region
locations need to be fully supported, with a consistent rule used to
define what is and is not fully supported.


Fixed/etc type rules
--------------------------
IDs with a fixed offset

Examples: GMT, UTC, Etc/GMT-9

Proposal: No change, retain in the main files unless a particular ID
is considered obsolete or deprecated


Are there any more classifications I've missed?

Stephen

[1] https://mm.icann.org/pipermail/tz/2021-September/030857.html
[2] https://www.iana.org/help/eligible-tlds