<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">Two different issues are being confused.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">1. Don't have timezone IDs span country countries (specifically for,<i> country code</i>).</div><div class="gmail_default" style="font-family:times new roman,serif">2. Use a short English name of countries in the timezone IDs.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">#1 former I fully agree with. The <a href="https://www.ietf.org/timezones/tzdb-2021e/zone1970.tab" target="_blank">https://www.ietf.org/timezones/tzdb-2021e/zone1970.tab</a> 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 <a href="https://www.eff.org/cyberspace-independence">https://www.eff.org/cyberspace-independence</a>). 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.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">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 <b>each</b> timezone ID (not just the ones in the zone table); IDs with the same coordinates would have the 'same place' links.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">#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.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 5, 2021 at 3:11 PM Guy Harris via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Nov 5, 2021, at 2:53 PM, Brian Park via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br>
<br>
> 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).<br>
> <br>
> 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.<br>
<br>
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.)</blockquote></div>