Tim Parenti replied to Sorel Si:

The zone in question was moved from the 'europe' file to 'backzone' in release 2022d and, as such, is no longer referenced in the 'zone*.tab' files. ... Any remaining references to Europe/Uzhgorod exist for backwards- compatibility purposes only. In almost all cases, Europe/Kyiv should be used instead.

There’s another problem, though. The tz database is not a gazetteer or other official reference to the “correct” spelling of city names. The identifiers in the tz database are not meant to be presented directly to users as part of a UI. Rather, tzids are internal identifiers, sort of like variable names or URLs or API endpoints. They are intended to be stable. When you change one, you create an incompatibility with systems that expect the old name. The theory file says to “Use mainstream English spelling” in place names, which often leads to requests like this on the basis that the locally preferred spelling or transliteration must automatically be the mainstream English spelling. That’s not reality. It takes time for another government’s preference to take hold in English usage—we still don’t really use “Czechia” in the US, and might never do so—but even if and when it finally does, the stability problem remains. Although the full tz database includes a system of links, such that clients looking for an old tzid can have it automagically mapped to the new one, there are systems out there that don’t use this mechanism. They look up the names directly, or they provide mappings between tzids and time zone names used by other systems. (CLDR is an example of this.) When a tzid is changed, it breaks the client, at least until the maintainers of the client get a chance to react with an update. The theory file goes on to say, “If a name is changed, put its old spelling in the 'backward' file as a link to the new spelling. This means old spellings will continue to work.” This is great for clients that understand ‘backward’ and linking, but breaks the others. I would prefer to see the administrative policy changed in the opposite direction that Sorel has in mind, making the _new_ spellings the aliases, and keeping the existing identifiers stable for systems that need that stability. (Lest there be any misunderstanding, this has nothing to do with being pro-Ukraine or pro-Russia.) -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

On Fri, May 16, 2025 at 12:01 AM Doug Ewell via tz <tz@iana.org> wrote:

There’s another problem, though. The tz database is not a gazetteer or other official reference to the “correct” spelling of city names. The identifiers in the tz database are not meant to be presented directly to users as part of a UI.

Rather, tzids are internal identifiers, sort of like variable names or URLs or API endpoints. They are intended to be stable. When you change one, you create an incompatibility with systems that expect the old name.

The theory file says to “Use mainstream English spelling” in place names, which often leads to requests like this on the basis that the locally preferred spelling or transliteration must automatically be the mainstream English spelling. That’s not reality. It takes time for another government’s preference to take hold in English usage—we still don’t really use “Czechia” in the US, and might never do so—but even if and when it finally does, the stability problem remains.

And you should change Rome to Roma! (this is a joke, I actually understand that the tzdb uses English names. Rome/Roma and Uzhgorod/Uzhhorod is the same case though, with the aggravation that Uzhgorod has been the official transliteration since the stone age and Uzhhorod is the result of a very recent change in the official transliteration...)

(Lest there be any misunderstanding, this has nothing to do with being pro-Ukraine or pro-Russia.)

Absolutely.