[tz] Recent conversions of zones to aliases

[Mark Davis ☕️]

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.

http://www.unicode.org/cldr/charts/26/by_type/timezones.southern_asia.html#1ec17cd0640b24d7

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'll disagree.

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:

http://unicode.org/cldr/trac/browser/trunk/common/bcp47/timezone.xml

That continues to distinguish by country, even where items are aliased in
the TZDB.

<type name="zwhre" description="Harare, Zimbabwe" alias="Africa/Harare"/>
<type name="mzmpm" description="Maputo, Mozambique" alias="Africa/Maputo"/>

Where there are multiple aliases, the first is the canonical one:
<type name="inccu" description="Kolkata, India" alias="Asia/Calcutta
Asia/Kolkata"/>

So you'll see translations for those canonical IDs like:
<zone type="Asia/Calcutta">
<exemplarCity>Калькутта</exemplarCity>
</zone>

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.

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'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.

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't at all want to seem like I'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!)


Mark <https://google.com/+MarkDavis>

*— Il meglio è l’inimico del bene —*

On Fri, Oct 3, 2014 at 8:49 PM, Guy Harris <guy at alum.mit.edu> wrote:

>
> On Oct 3, 2014, at 5:43 AM, Mark Davis ☕️ <mark at macchiato.com> wrote:
>
> > 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't matter much (and Kosovo
> is a special case).
>
> 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 "put up a bunch of tzids and let the user pick
> one".)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20141017/cdf12d34/attachment.html>