[tz] Request for Standardization of Kyiv Time Zone Naming

[Justin Grant]

Hi Dmytro - The IANA Time Zone Database switched
<https://github.com/eggert/tz/blob/d1ce7788d47a00c2c0f233f96c3106d95883be0e/NEWS#L413>
to use Europe/Kyiv in Release Release 2022b in August 2022. The deprecated
name for this time zone, Europe/Kiev, remains in TZDB only as a Link
<https://github.com/eggert/tz/blob/d1ce7788d47a00c2c0f233f96c3106d95883be0e/backward#L314>
to the new name.

However, as you've observed, changes in TZDB are sometimes slow to arrive
in different OSs and programming platforms. In particular, many platforms
consume TZDB indirectly via  the Unicode ICU native library, which in turn
uses data in Unicode CLDR
<https://github.com/unicode-org/cldr/blob/dace6c6b5672cbc70d6135f9ad82107b59142a61/common/bcp47/timezone.xml#L398>
to determine which IANA time zone identifiers are valid. Specifically, they
typically use the TimeZone::getCanonicalID
<https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#a7ec9cea4e406bd625e0fe1b058134b5c>
in
C++ (or its Java equivalent) to resolve deprecated IDs (like
Asia/Ulan_Bator) to their corresponding primary ID like Asia/Ulaanbaatar.
This ICU API always returns the first ID listed in CLDR. For example, see
the line below from the latest CLDR timezone.xml
<https://github.com/unicode-org/cldr/blob/dace6c6b5672cbc70d6135f9ad82107b59142a61/common/bcp47/timezone.xml#L270C88-L270C104>
:

<type name="mnuln" description="Ulaanbaatar (Ulan Bator), Mongolia"
alias="Asia/Ulaanbaatar Asia/Ulan_Bator"/>

ICU and CLDR, for sensible reasons to avoid breaking existing applications,
never change the ID returned by TimeZone::getCanonicalID
<https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#a7ec9cea4e406bd625e0fe1b058134b5c>.
So even though some deprecations happened long ago in TZDB, like
Asia/Calcutta => Asia/Kolkata, ICU still reports the old ID (like
Asia/Calcutta) in TimeZone::getCanonicalID
<https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#a7ec9cea4e406bd625e0fe1b058134b5c>
because
CLDR lists it first in the list:

<type name="inccu" description="Kolkata, India" alias="Asia/Calcutta
Asia/Kolkata" iana="Asia/Kolkata"/>

You'll notice that this line has an iana attribute, which (as you'd guess
from its name) communicates the ID that is the current ID in TZDB, even if
Asia/Calcutta is still first in the list of IDs in the alias attribute.
This iana attribute is new, introduced in CLDR 44
<https://cldr.unicode.org/index/downloads/cldr-44> that was only released a
few weeks ago. This new attribute powers the new ICU TimeZone::getIanaID
<https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#a7e182f60aa75c78a623065ad8470d290>
API which was released in ICU 74.1 <https://icu.unicode.org/download/74> (see
this JIRA ticket <https://unicode-org.atlassian.net/browse/ICU-22452>)
which was also released a few weeks ago on 31-10-2023. This new API finally
provides the ability for ICU client apps (like Google Chrome, Apple Safari,
and Node.js) to be able to return the most up-to-date IANA IDs.

As you'd expect, the same iana attribute has been added
<https://github.com/unicode-org/cldr/blob/dace6c6b5672cbc70d6135f9ad82107b59142a61/common/bcp47/timezone.xml#L398C13-L398C146>
for Kyiv's time zone:

<type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev
Europe/Kyiv Europe/Zaporozhye Europe/Uzhgorod" iana="Europe/Kyiv"/>

As soon as ICU clients switch over to use the new TimeZone::getIanaID
<https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1TimeZone.html#a7e182f60aa75c78a623065ad8470d290>
API,
you will see Europe/Kyiv being returned as you'd expect.

That said, I'm not sure when Chrome and Safari (or, more specifically,
their ECMAScript engines V8 and JavaScriptCore) will switch over to the new
API. But I'd expect it to happen sometime in 2024.

Thanks for asking about this important issue!

Justin Grant
(I'm part of the team defining ECMAScript's Temporal
<https://github.com/tc39/proposal-temporal> date/time API and I've been
working with CLDR and ICU to fix this problem you reported)

On Fri, Nov 10, 2023 at 9:17 PM Dmytro Shynkarenko via tz <tz at iana.org>
wrote:

> Dear IANA Team,
>
> I'm reaching out on behalf of our team at Tutorpeers (Tutorpeers.com)
>
> I'm reaching out to address a significant concern related to the naming of
> Ukraine's capital in time zone databases. At present, there are two
> spellings in use: "Kiev" and "Kyiv." The latter, "Kyiv," is the correct
> Ukrainian spelling and pronunciation, which honors the country's
> sovereignty and the preferences of its people.
>
> The use of "Kiev," which is derived from the Russian language, has become
> increasingly problematic, especially considering Russia's ongoing
> aggression against Ukraine. This issue hits close to home for me, not only
> because of my Ukrainian roots but also due to the feedback we've received
> from our Ukrainian user base. Numerous customers have reached out to us,
> expressing discomfort and disapproval of the "Kiev" spelling, given the
> current circumstances.
>
> Our platform has taken a clear stance on this issue, and we urge IANA to
> consider the implications of language and to update its time zone databases
> accordingly. By standardizing the "Kyiv" spelling, we can collectively show
> support for the Ukrainian community and respect their cultural and national
> identity.
>
> After speaking to your colleague Candice Montoya I was pleased to learn
> that the spelling change to "Europe/Kyiv" has already been implemented in
> the Time Zone Database as of August 2022. This update is much appreciated
> and reflects a positive and respectful acknowledgment of the correct naming
> convention.
>
> However, I've noticed that the previous spelling, "Kiev" still appears in
> some instances. Please confirm if this is intended for backward
> compatibility with existing systems. And if so, is there a planned timeline
> for its eventual deprecation in favor of the updated "Kyiv" spelling?
>
> Understanding the strategy for phasing out the old spelling would be
> incredibly helpful for our team and user community as we navigate these
> changes and ensure we provide the most current and accurate information.
>
> Thank you once again for your attention to this matter.
>
> Regards, Dmytro
> Project Coordinator at Tutorpeers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20231111/e7ad3c50/attachment.htm>