On Nov 27, 2020, at 1:19 AM, Clive D.W. Feather <clive@davros.org> wrote:
Andriy Ivanchenko said:
Here https://zakon.rada.gov.ua/laws/show/55-2010-??#Text you can see transliteration at the state level, if that helps. Maybe it's time to introduce multilingual support in your database?
The time zone database is not the place for multilingual support or characters other than ASCII.
The Theory file: https://data.iana.org/time-zones/theory.html says, among other things: Here are the general guidelines used for choosing timezone names, in decreasing order of importance: * Use only valid POSIX file name components (i.e., the parts of names other than '/'). Do not use the file name components '.' and '..'. Within a file name component, use only ASCII letters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer Asia/Brunei to Asia/Bandar_Seri_Begawan. Exceptions: see the discussion of legacy names below. ... * Use mainstream English spelling, e.g., prefer Europe/Rome to Europa/Roma, and prefer Europe/Athens to the Greek Ευρώπη/Αθήνα or the Romanized Evrópi/Athína. The POSIX file name restrictions encourage this guideline.
There are other projects which do this, such as CLDR (http://cldr.unicode.org/translation/timezones).
Yes. If you want to, for example, provide a user interface to allow a user to choose the tzdb region for their machine, it should, at minimum, use the CLDR's name for the exemplar city. Ideally, it should provide a *choice* of cities, so, for example, somebody in Beijing doesn't have to choose Shanghai (whether in Simplified Chinese or in English or...), and somebody in San Francisco doesn't have to choose Los Angeles.
The names used in the time zone database are identifiers and long-term stability of these names is an important matter. It is not an absolute - such name changes have been made before
For example, Asia/Calcutta - Asia/Kolkata in March 2008.