On Oct 3, 2018, at 10:04 AM, Tim Parenti <tim@timtimeonline.com> wrote:

In particular, the spellings in current use by this project generally remain much more common in English-language media. This project attempts to reflect mainstream English-language spellings for place names (see theory.html), and explicitly does not attempt to reflect transliterations.

And, again, for the 5 trillionth time: If a user interface shows the tzdb region names to most end users and requires most end users to set the tzdb region by selecting from a list of tzdb region names - and this includes names generated from tzdb region names, e.g. "helpfully" using "Los Angeles" in the "America" region rather than "America/Los_Angeles" to select the US Pacific time zone - it is not a good user interface. Those names are identifiers for software use, just as LANG environment variable settings such as en_US.UTF-8 are identifiers for software use, *not* names that most end users should have to deal with, so making the names "look appropriate" is not the highest priority.

Very good summary of the issue. Thank you. Yes, I would agree that for those that state they have issues with these names, they appear incorrect or humiliating - whether that was the intent or not. On 2018-10-03 17:13, Volodymyr Kostyrko wrote:

03.10.18 20:46, Guy Harris wrote:

...

On Oct 3, 2018, at 10:04 AM, Tim Parenti <tim@timtimeonline.com> wrote:

...

In particular, the spellings in current use by this project generally remain much more common in English-language media.  This project attempts to reflect mainstream English-language spellings for place names (see theory.html), and explicitly does not attempt to reflect transliterations.

And, again, for the 5 trillionth time:

If a user interface shows the tzdb region names to most end users and requires most end users to set the tzdb region by selecting from a list of tzdb region names - and this includes names generated from tzdb region names, e.g. "helpfully" using "Los Angeles" in the "America" region rather than "America/Los_Angeles" to select the US Pacific time zone - it is not a good user interface.

Those names are identifiers for software use, just as LANG environment variable settings such as en_US.UTF-8 are identifiers for software use, *not* names that most end users should have to deal with, so making the names "look appropriate" is not the highest priority.

I must admit that you are right. But the point is that this is not the final position everyone can agree with.

Taking PHP community as a an example they are using raw zone names in their configuration files. If any thirdparty vendor would try to translate this zones in his application he will face a choice - to be correct about zone naming according to each language or to forfeit correctness in favor of clear and unambiguous configuration. And he should choose the latter. I can't blame him neither.

Renaming things others depend upon is also a very sloppy path that shouldn't being followed so easily. Though this raises a problem similar to "master-and-slave" concept. Most people are feeling fine with the names as they are just a hollow words that mean nothing to them, though for a very limited number of people who faced slavery or humiliation this will be just a trigger and they will not stop fighting to make everyone else stop treating this words as "normal" and not "shameful". Most of you feel nothing about Kiev/Kyiv difference, but for a lot of Ukrainians the former is a sign of a communist slavery, the mark of alien possession over they father's land. Leaving things as they are will not solve the problem for them, and they wouldn't stop trying to change it. That's politics. Even if you try to stay unbiased and techy you have to choose something, and this choice will make your side.

Probably this can be easily solved by scrapping full town names and switching to some indices like UAK/UAZ/UAU but that's totally out of the scope of my knowledge of tz database rules and principles. And also in this case I'm a biased person. Totally not for me to decide.

Thank you.

On 2018-10-04 08:45:03 (+0200), Paw Boel Nielsen via tz wrote:

...

...

it is not a good user interface. I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.

This has been proposed several times. The main downside to that idea is that it would make the tzdb a lot more difficult to maintain. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information

On Oct 3, 2018, at 11:45 PM, Paw Boel Nielsen via tz <tz@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.

I've already made similar suggestions; that would get rid of the "why isn't it Asia/Beijing"? complaints, and would also mean I wouldn't get shown "America/Los_Angeles" as the appropriate choice even though I'm about 500 km from there.

On Oct 4, 2018, at 02:45, Paw Boel Nielsen via tz <tz@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. 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. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | Like the ski resort of girls looking for husbands and husbands | | looking for girls, the situation is not as symmetrical as it might | | seem. | | -- Alan McKay | |----------------------------------------------------------------------|

On 4 Oct 2018, at 15:33, Michael Douglass <mikeadouglass@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@iana.org <mailto:tz@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

I suggested a completely backward compatible approach. Downstream consumers can have a form of the data that looks as it does now. The argument we are supposedly trying to make is that NOBODY should be presenting these names to users - they should be using the tzid as a key to a localized lookup so UI wise there's no difference. I don't think we can use 'misuse' of those names as a reason not to change. There is also the point that some are reluctant to use the Olson data at least because it's tied to politically sensitive names. Having the originators maintain a UID at least satisfies that problem. On 10/4/18 13:02, Fred Gleason wrote:

On Oct 4, 2018, at 12:35, John Haxby <john.haxby@oracle.com <mailto:john.haxby@oracle.com>> wrote:

...

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.

Exactly. At *some* point in the chain, these zones need to get turned into geographical names that people can recognize. In some regions, that naming process is fraught with dispute and emotion; unfortunately, due to the very nature of what tzdb is and does, we are never going to be free from that aspect. Thus, changing the current identifiers would merely add confusion for users and complexity to the code without addressing the essence of the issue. Yes - these discussions are always fraught with dispute and emotion.

The point here is to distance this group that maintains the zone data from some other group that does localization. With a little care most consumers of the data won't see the difference.

That cartoon from Xkcd posted here last week [https://xkcd.com/2050/] somehow feels relevant…  :)

I think that cartoon identifies the type of discussion that SHOULD take place in this group.

Cheers!

|----------------------------------------------------------------------| | Frederick F. Gleason, Jr. |              Chief Developer         | |                           |              Paravel Systems         | |----------------------------------------------------------------------| |         A room without books is like a body without a soul.         | |                                         -- Cicero         | |----------------------------------------------------------------------|

On Oct 4, 2018, at 2:37 PM, Ken Murchison <murch@fastmail.com> wrote:

I happen to agree with Mike that the naming of the zones can be extracted out as meta-data to go along with the tz rulesets. The IANA db can use UUIDs, urns or whatever to label the zones and also provide a mapping from the current names to the opaque ids. Consumers of the data can use the existing mapping or create their own.

I'm still not sure why there is a need to do a whole pile of work on the tzdb, merely to work around people who ignore the documentation. paul

On 4 Oct 2018, at 18:42, Michael Douglass <mikeadouglass@gmail.com> wrote:

The argument we are supposedly trying to make is that NOBODY should be presenting these names to users - they should be using the tzid as a key to a localized lookup so UI wise there's no difference. I don't think we can use 'misuse' of those names as a reason not to change.

However, you cannot expect enterprise system providers to break current applications because of that 'misuse'. If you want to make the change then you need to deal with the fact that it's going to take at least a decade before the existing applications are no longer supported. During those 10 years or more you are going to have to keep dealing with those people who think that regions should be named differently. The better approach, I suspect, is to educate. jch

On Oct 4, 2018, at 1:11 PM, Steve Allen <sla@ucolick.org> wrote:

[EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information.

On Thu 2018-10-04T10:33:55-0400 Michael Douglass hath writ:

...

Kicking it up a level is exactly what's needed.

...

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.

I am going to disagree with this based on history. These sorts of arguments about responsibility, functionality, and international legal and bureaucratic issues are eerily similar to the process by which the world got leap seconds, with the responsibility for those split between multiple agencies in a way that utterly obscures what is the goal and who is in charge. Better to keep that all in one place that is clearly documented as to how it should and should not be used and where the alternatives are for folks who do not like the base form.

True. But the whole timezone thing end to end, all the way to the user interface, is not intended to be managed in one place. The top end of TZDB is (intended to be) an internal interface, not a user interface. The problem is that some people don't bother to deliver the user interface and use the internal interface directly. That would be ok, except for the fact that they then complain that the encoding at the internal interface isn't user friendly. The answer is "no, and it isn't supposed to be, read the documentation". Unfortunately, it keeps coming up N times per year. And not everyone responds to the answer in the reasonable way that the requester did on this occasion. paul

On 10/4/18 16:00, Paul Eggert wrote:

On 10/4/18 7:33 AM, Michael Douglass wrote:

...

Opaque ids are what some consumers have been asking for for some time because of the political implications of the names.

I would rather not change the zone names currently used in tzdb source files, as the change would be a hassle for both maintainers and users, and the existing names simplify maintenance since they are easier to read than opaque IDs would be.

Although we could add an auxiliary table that maps existing names to short, stable, and reasonably opaque identifiers, CLDR is already maintaining such a table and it'd be confusing if we attempted to duplicate that work; plus, such a table would not be useful to tzcode so it wouldn't be tested well by us. For now, we are probably better off improving the already-existing suggestion to use CLDR facilities for consumers worried about politics. Proposed patch attached.

I believe this group should be the authoritative source for such an id. What happens when zones split etc? There's presumably a delay between the split and an appearance in cldr data. While we continue to provide only the name as the key to a zone people will continue to mistake it for something they can present to users. Criticizing such people isn't going to stop it. Not having a uid in the data means we have no choice but to use that 'human-readable' key. I'd propose adding a UID to VTIMEZONE - happy to write the spec - but at the moment there's no usable value.

On 10/4/18 8:36 PM, Phake Nick wrote:

I would suggest putting relevant info in the readme or such instead of theory for visibility purpose.

I drafted some text along those lines, but after a cooling-off period I reread it and it sounded too negative. README is a high-level description of the project that should be welcoming, and putting something in there that boils down to "Don't waste our time trying to rename Asia/Shanghai" is off-putting. Even CONTRIBUTING is mostly too high-level for this sort of thing. However, CONTRIBUTING can suggest that if the contribution might be controversial then one should read theory.html first (and give a URL to theory.html). Also, while I'm at it, README can be reworked slightly. Proposed patch attached.

On 10/5/18 10:21 AM, Paul.Koning@dell.com wrote:

Perhaps just describe the issue specifically: before proposing zone name changes, read the discussion about zone names in the theory file.

Sure, that's easy enough. Proposed patch attached.

On 10/4/18 9:58 PM, Guy Harris wrote:

we should perhaps also emphasize that a UI should*not* treat the name that happens to be used in a tzdb region ID as*the* city to offer - it should offer other cities as well - to handle the "please pick a different city so people in {San Francisco, Beijing, ...} won't have to select {Los Angeles, Shanghai, ...}" problem.

I drafted the attached that does something along those lines. It deliberately sticks to the Uzhhorod/Uzhgorod example instead of better-known disputes like Kyiv/Kiev, Beijing/Shanghai, and San Francisco/Los Angeles (don't get me started!), to try to lessen the number of readers that might be offended. It also mentions using a map, which is out of our scope and also can rile users (ask Microsoft about the India-Pakistan border...) but we might as well mention geolocation while we're in the neighborhood, so to speak.

03.10.18 20:07, Paul Eggert wrote:

Paul.Koning@dell.com wrote:

...

This exact topic has been discussed (and rejected) many times in the past, several times per year.

We can add a comment to the 'europe' file so that potential contributors can understand the issues better before proposing patches.  Proposed patch attached.

I just now did a Wikipedia search from Los Angeles, and "Uzhgorod" had about 2,860,000 hits whereas "Uzhhorod" had 1,040,000, so it seems that traditional English spellings are still holding strong for smaller Ukrainian cities as well.

Thank you for looking into this. I wasn't careful enough to read that much of archives, only checked a few last month. Alas, mailing list archives are not that human friendly. So having a comment outlining current state and reasoning right at the `europe` would be most helpful. Adding a comment is probably the easiest way to nail down guys like me that are generally trying to fix obvious error (that what we think) and see no other attempts to do that logged in the same file. Probably a link to ftp://ftp.iana.org/tz/theory.html wouldn't harm too. Idea expressed by Guy Harris should go there too probably. Though I wouldn't agree with him completely it's worth mentioning in the first place. Outlining current status for Uzhhorod/Zaporizhzhia would be nice too, for example if you check Wikipedia you can find Zaporizhia as the most commonly used form. While taking some place in the comments this will direct people to some real qualifiers and will outline what should be done to change things. Big thanks for your time and looking into this. Hope after this changes the steady flow of patches will cease. :) -- Sphinx of black quartz judge my vow.