"Gwillim Law" <gwil@mindspring.com> writes:

I hope we'll resist making frequent changes to the zone names. Please remember that every change has a cost. In this case, there's the labor of updating databases, resource files, source code, etc.

Yes. For the two proposed changes Asia/Ashkhabad -> Asia/Ashgabat and Asia/Thimbu -> Asia/Thimphu, we'd definitely add entries to the "backward" file, so that any existing users could continue to use the old names.

Do not change established names unless they become ambiguous or shockingly incorrect.

That is a pretty conservative rule. I think I'm a bit more liberal, at least for names that are rarely used. I'd be somewhat surprised if anyone is currently using either of the two names in question as a TZ string. (Thimphu has 20,000 people and no stoplights. :-) The "backward" file let us survive the Great Renaming of 1993 (e.g. "US/Eastern" -> "America/New_York") with little problem, so I'm not to worried about renaming Thimbu. Also, a problem with this rule is that it's hard to define "shockingly incorrect" without going into politics. For example, if we had established the tz database in 1940 and had needed an entry for Asia/Peiping, would that name be "shockingly incorrect" by now? The name "Peiping" implies that Beijing is not the capital of China, and that would probably shock most Chinese; but it wouldn't shock most English-speakers because they don't have a feel for the Chinese etymology. This is an extreme case, but I hope you see what I mean. How about the following more liberal rules instead? Do not change established names if they only marginally violate the above rules. For example, don't change the existing name `Rome' to `Milan' merely because Milan's population has grown to be somewhat greater than Rome's. If a name is changed, put its old spelling in the `backward' file.