[tz] Request for change to the tz database

[Brian Inglis]

On 2021-02-08 17:07, Robert Elz wrote:
>      Date:        Mon, 8 Feb 2021 14:28:24 -0800
>      From:        Guy Harris <gharris at sonic.net>
>      Message-ID:  <90554020-92B9-46CA-83DF-AC914E612DBE at sonic.net>
> 
>    | None; the issue is that the city names are *English-language* city names,
> 
> Yes.
> 
>    | and should reflect the most common English-language transliteration
>    | of non-English-language names.
> 
> But not that.
> 
> English names (whatever they are of) do not need transliterating into English,
> they already are.  For some places English uses what are (effectively)
> transliterations of the local name, for others, the name isn't even similar
> Bangkok's name in Thai transliterates as Krungthep[MaHa.....] (it keeps
> going, it is a very long name, but is most commonly abbreviated to Krungthep)
> (the leading K is pronounced like a G in English).   In tz we use Bangkok,
> as that's the English name.
> 
> I don't much care what Kiev/Kyiv is called in English (Kiev is what it
> has always been to me, and will probably remain that way, but it isn't
> as if I use the name anywhere other than here).    However, the content
> of recent messages makes it appear that someone has started a campaign
> ("Please help get the name changed, by sending e-mail to... and in it
> say ...").   Because of that I am (for now) opposed to making any change
> at all to this one (and I don't care what Google, or various newspapers,
> etc, have decided to do).   If we start paying attention to this kind
> of thing we're simply inviting it to happen again.   So say, "Sorry, no,
> your campaign has caused us to decide to retain the current name" and
> nothing else.

Agreed!
One of the most important lessons in developing and maintaining production 
software is learning to say "No!" sometimes "Hell, NO!" in response to some 
issues or requests that provide no benefit to the project or product, but may 
only introduce bugs in the project or product, or downstream.

In the commercial world we can say, these parts make sense, and if you want us 
to do that for you, we estimate it will cost $X00k/$XM to conduct and provide an 
impact assessment, develop that, change all interfaces, retest, and redeploy the 
app, site, system, and everything.

In the open source world, maintainer effort and time is the cost, as is the 
impact downstream on other projects, who have to conduct and provide an impact 
assessment to decide do we want to pass on these changes to our downstreams, or 
maintain patches to revert them to maintain stability to our downstreams, and do 
we have that capability if the project has constraints?

Given tz downstreams are every major system and vendor in the world, and other 
projects like CLDR, who have their own release schedules, and possibly 
contributor or volunteer limits on the time and effort they can provide, 
stability of *ALL* external interfaces *MUST* be a major consideration.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]