<div dir="ltr"><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif">Some alias relations are vastly different than others. The distinction between Asia/Calcutta and Asia/Kolkata does not matter for the purposes of localized names; they really identify the same place. So we need to map them together for the purpose of getting localized names. </div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><br></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><a href="http://www.unicode.org/cldr/charts/26/by_type/timezones.southern_asia.html#1ec17cd0640b24d7">http://www.unicode.org/cldr/charts/26/by_type/timezones.southern_asia.html#1ec17cd0640b24d7</a></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><br></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif">However, the difference between Asia/Tokyo and Asia/Seoul (even if they had the same rules) is very important to end users, and must be maintained. For localization, we are lucky in a way that the rules are sufficiently different that for the most part cities in one country are not aliased to those in another. That is of course not an accident; timezone rules are determined by territory governments, so it is quite likely that at some point in time they&#39;ll disagree.</div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><br></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif">In CLDR we have to have stable canonical IDs for the purposes of localization, ones that distinguish by country; we originally based them on zone.tab, but had to deviate from that because it is unstable. So what we use to canonicalize is in the following:</div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><br></div><div class="gmail_default" style><font face="times new roman, serif"><a href="http://unicode.org/cldr/trac/browser/trunk/common/bcp47/timezone.xml">http://unicode.org/cldr/trac/browser/trunk/common/bcp47/timezone.xml</a></font></div><div class="gmail_default" style><font face="times new roman, serif"><br></font></div><div class="gmail_default" style><font face="times new roman, serif">That continues to distinguish by country, even where items are aliased in the TZDB.</font></div><div class="gmail_default" style><font face="times new roman, serif"><br></font></div><div class="gmail_default" style><font face="times new roman, serif"><div class="gmail_default">&lt;type name=&quot;zwhre&quot; description=&quot;Harare, Zimbabwe&quot; alias=&quot;Africa/Harare&quot;/&gt;</div><div class="gmail_default"><div class="gmail_default">&lt;type name=&quot;mzmpm&quot; description=&quot;Maputo, Mozambique&quot; alias=&quot;Africa/Maputo&quot;/&gt;</div><div class="gmail_default"><br></div><div class="gmail_default">Where there are multiple aliases, the first is the canonical one:</div><div class="gmail_default"><div class="gmail_default">&lt;type name=&quot;inccu&quot; description=&quot;Kolkata, India&quot; alias=&quot;Asia/Calcutta Asia/Kolkata&quot;/&gt;</div><div class="gmail_default"><br></div><div class="gmail_default">So you&#39;ll see translations for those canonical IDs like:</div><div class="gmail_default"><div class="gmail_default"><span class="" style="white-space:pre">                        </span>&lt;zone type=&quot;Asia/Calcutta&quot;&gt;</div><div class="gmail_default"><span class="" style="white-space:pre">                                </span>&lt;exemplarCity&gt;Калькутта&lt;/exemplarCity&gt;</div><div class="gmail_default"><span class="" style="white-space:pre">                        </span>&lt;/zone&gt;</div></div><div><br></div></div><div class="gmail_default">So if some system needs stable identifiers, it may be possible for it to use the CLDR identifiers. The use of those is, however, predicated on using an underlying TZDB for the calculation of times associated with those identifiers.</div></div></font></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><br></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif">I agree if we had had just arbitrary IDs, there would have been less of a reason to have zone.tab be unstable, because people wouldn&#39;t have felt the need to have destabilizing changes simply for spelling changes, etc. On the other hand, items like Asia/Calcutta really should have always been treated simply as internal IDs, never shown directly to end users. So there should have been no need to have destabilizing changes just for spelling, etc. And there is advantage for programmers debugging code to be able to see something like Asia/Calcutta instead of some incomprehensible ID like TZ597. </div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif"><br></div><div class="gmail_default" style="font-family:&#39;times new roman&#39;,serif">On the other hand, in CLDR we did actually need to have short alphanumeric IDs for use in restricted environments like BCP47, so you see the name=... values above. Those are based on the UN/LOCODE ids, which are vaguely mnemonic: but we had to add extensions for cases where those codes are deficient, and impose a stability rule on our usage, because UN/LOCODE ids are also not guaranteed to be stable—and are far less well maintained than the TZDB. (I don&#39;t at all want to seem like I&#39;m slamming the TZDB: the work done for so many years by the TZ maintainers has has been a true service to the world as a whole!)</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font face="&#39;times new roman&#39;, 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"><br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><a href="https://google.com/+MarkDavis" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="&#39;times new roman&#39;, serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div>
<br><div class="gmail_quote">On Fri, Oct 3, 2014 at 8:49 PM, Guy Harris <span dir="ltr">&lt;<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Oct 3, 2014, at 5:43 AM, Mark Davis ☕️ &lt;<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>&gt; wrote:<br>
<br>
&gt; But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn&#39;t matter much (and Kosovo is a special case).<br>
<br>
</span>Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics (and of population shifts).  (That might also force systems to have better mechanisms for selecting time zones than &quot;put up a bunch of tzids and let the user pick one&quot;.)<br>
</blockquote></div><br></div>