[tz] Asia\Nicosia

[Guy Harris]

On May 24, 2018, at 10:45 AM, GsaTitanium <gsatitanium at gmail.com> wrote:

> i have checked CLDR. Under their Time Zone section say and i quote: "The time zone IDs (tzid) are language-independent, and follow the TZ time zone database [Olson] and naming conventions.” Link: https://unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names
> 
> Where Olson is referring to iana tz database. Link: https://unicode.org/reports/tr35/tr35.html#Olson 
> 
> CLDR say that by locale display name may very. Basically what you said to me. But their core data are getting it from iana. So basically iana data: Asia/Nicosia. must change to Europe/Nicosia.

"Asia/Nicosia" and "Europe/Nicosia" are tzids.  As Paul Eggert explained, they are not intended to be shown to end users.  The CLDR gives the display names; *those* are what should be shown to end users.  CLDR does *not* get the display names from IANA, so the IANA names don't need to change in order to make the CLDR display names correct.

> I understand that core data must not be disabled to any user and that the locale names must be showed, but developers are skipping the process to include the locale data, resulting to display Asia/Nicosia in some programs.

This is why I've suggested switching to using some form of very-definitely-not-intended-for-humans-to-be-able-to-read IDs for tzdb zones, so that any developer who "[skips] the process" ends up with an app offering choices such as "67382" or "SKB78" to end users, the end users complain, and they're forced to stop offering those choices (or, if it's some small embedded device that can't support the CLDR database, to have a printed manual giving tzids for locations, or whatever).

> Are they wrong for not including locale data? Yes they are. But i am trying to resolve the issue from the root, in this case is iana.

If "the issue" is end users being forced to say "Shanghai" when they're in Beijing, or to say "Kiev" when they're in Київ, or to say "Asia/Nicosia" when they're in an EU country, one can quite validly argue that the root of the problem is in the software being, as you say, wrong in using the tzid rather than the CLDR display name (or, even better, offering a list of cities and towns, in the locale's language and script, so they don't have to choose a tzid region, they can choose a nearby city or town), rather than being the IDs that the IANA TZDB arbitrarily chooses not being convenient for end users.

> I undestand that you do not like to change data and that your data are based in geological locations and not political. But in this case your data are misleading.

Misleading to end users forced to use them.  Again, I view this as being the fault of the software developers, not the TZDB maintainers.

(As far as I'm concerned, *everybody* developing tzdb region selecting software should be taken to a nearby Apple Store and shown macOS's selector, in detail, and told "OK, your job is now to do something that works as well as this, if not better.)

> Again thank you for replying to me, i appreciate it. I hope in the near future you change you way of doing business before a new organisation come and become the new standard for tz database.

Perhaps many of the people here would enjoy watching some new organization try to do that, especially if it means *they* would no longer have to spend time and energy maintaining the database and dealing with zone naming complaints.