Two different issues are being confused.

1. Don't have timezone IDs span country countries (specifically for, country code).

2. Use a short English name of countries in the timezone IDs.

#1 former I fully agree with. The https://www.ietf.org/timezones/tzdb-2021e/zone1970.tab file goes a long way in this direction, and it wouldn't be hard to add some timezone IDs with Links to complete the set. Countries are important entities (denying that feels like https://www.eff.org/cyberspace-independence). While it may seem pointless to add timezone IDs for some rocks like Heard and McDonald Islands, there are only a few of those, and for testing purposes it is better to be complete.

Note: I like the previous proposal to cleanly distinguish between those Links that are between IDs that really refer to the same place (just different spelling or name), and those that refer to different places. Alternatively, a step that would also serve to disambiguate, would be to have approximate coordinates for each timezone ID (not just the ones in the zone table); IDs with the same coordinates would have the 'same place' links.

#2 is disruptive, and serves no purpose. The timezone IDs are no more than internal IDs, with a bit of mnemonic flavor just for internal recognition. No real implementation should present them to users; especially outside of the Anglosphere.

Mark

On Fri, Nov 5, 2021 at 3:11 PM Guy Harris via tz <tz@iana.org> wrote:

On Nov 5, 2021, at 2:53 PM, Brian Park via tz <tz@iana.org> wrote:

> 4) So maybe the solution is to use 2-letter or 3-letter ISO codes, instead of the shortened, quasi-English versions of the country names. So we get things like "CA/Eastern" or "CAN/Eastern", instead of "Canada/Eastern". Not very satisfying for Canadians or many other countries (except for Americans whose ISO codes "US" and "USA" match their colloquial usage perfectly).
>
> All this before we even get to the work of mapping various ISO countries (and their subregions if needed) to their corresponding canonical TZDB identifiers.

And "subregions" means more than just "time zone names" - Arizone isn't in the same tzdb region as Utah, so "US/Mountain" isn't sufficient here. I.e., even picking names for country/subregion combinations is going to involve some work and some decision-making. (And, while "US/Arizona" might work, "US/Indiana" won't - look for "Indiana" in the northamerica file. Then look at the whole Canada section - CA/{zone name} isn't going to suffice, either.)