[tz] Rename Ukrainian cities to their official transliterated names

[John Haxby]

> On 4 Oct 2018, at 15:33, Michael Douglass <mikeadouglass at gmail.com> wrote:
> 
> On 10/4/18 09:05, Fred Gleason wrote:
>> On Oct 4, 2018, at 02:45, Paw Boel Nielsen via tz <tz at iana.org <mailto:tz at iana.org>> wrote:
>> 
>>> I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
>> 
>> All that would do is kick the problem up a level. At some point, there has to be some sort of *map* that defines which tz entry relates to what specific geographical region. ‘Randomized’ identifiers merely mean that that map would have to be maintained separately, but would still have all of the socio-political baggage about proper spelling, transliteration, etc, etc.
>> 
> Kicking it up a level is exactly what's needed.
>> I think the current identifier arrangement is about the cleanest approach possible for what is an inherently messy task. TZ adopters do need to understand that those identifiers are essentially arbitrary keys into a database.
> There are many approaches to this but separating the tz data from names is both simple and backward compatible with end consumers though it requires a little work to change the data and the tools which use that data.
> 
> 1. Add a UID to the data
> 2. Remove the name
> 3. Create a mapping file of name<->uid
> 4. Change the tools to use that mapping file to create exactly the same output.
> 
> Opaque ids are what some consumers have been asking for for some time because of the political implications of the names.
> 
> The disadvantages to this approach are a little work.
> The advantages are that we can hand over maintenance of names to some other body (cldr?).
> We also get a uid which we know refers to a specific timezone
> 
> We can then update rfc5545 to use the UID property in VTIMEZONE and add text to point out that the tzid is for reference only.
> 
> Without this people will continue to start with the data they see and assume the id is for presentation to users. Eventually they might understand what's happening but there's always new people to confuse.

I don't think it's that simple.

The long-term stable Linux distros (eg RHEL, OL, CentOS, Ubuntu LTS) and possibly others (macOS?) are going to be with us for quite a few years yet and they will have to stick with the <region>/<locale> identifiers because they can't just break applications.  So even if the database changes to use opaque identifiers those installed systems will need to revert to the current system anyway.  At the moment, the Linux LTS distros will be supported for at least another decade.

Human behaviour would also be impacted, though to a lesser extent: it's not that hard to convert from typing "TZ=America/Los_Angeles date" to "TZ=$(find_timezone 'San Francisco') date" but a lot more people who complain about the various spellings of regions are going to ask wtf?

That decade or so for the switch over is also going to be confusing.   Systems will be using the current names but the master database will be using opaque identifiers and while a lot of us on this list will be fine with that, it's going to affect others as well.

I think, even so, this will not fix the problem.  Instead of complaining about the Europe/Kiev name, they'll be complaining about the spelling of the mapping from an opaque identifier to Europe/Kiev.

Perhaps, as was suggested earlier, an in-your-face statement of "timezone identifiers use common English spellings of names" would at least slow down the rate of spelling correction messages.

jch


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20181004/4c126f14/attachment-0001.html>