[tz] KyivNotKiev
Brian Inglis
Brian.Inglis at SystematicSw.ab.ca
Sat Nov 28 23:34:57 UTC 2020
Given that they are identifiers indicative of the location, there is no reason
to ever change them from their historical initially assigned POSIX base
character set values, unless technical time changes occur.
My comment was about what names native English readers and speakers are likely
to recognize and use and how long it will take to change that mentality. There
seems to be a lot of inertia resisting changes propagated by modern systems,
exemplified by support for Boris, Donald, and their ilk and supporters, who
would like to believe the clock could and should be turned back to maintain
20th century or maybe even Victorian norms.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On 2020-11-28 14:41, Phake Nick wrote:
> If we really don't wamt to deal with localization issue then we should use the
> original spelling instead of English/Latin Character transliteration
> Your comment on English translation name being stable is rather inaccurate,
> Alma-Ata have become Almaty, Bombay have become Mumbai, Leningrad have become
> Saint Petersburg.
> 在 2020年11月29日週日 05:08,Brian Inglis 寫道:
> If we are regarding these as English identifiers, we should be ignoring all
> these political arguments, and *STOP* adding alternate spellings, exccept for
> technical reasons when time zones split or combine.
>
> Alternate spellings and scripts are localization issues that should be dealt
> with by the likes of CLDR and ICU libraries. If the characters to be used were
> not in the POSIX base character set, we would have no hesitation just saying
> *NO*; we should have no hesitation just saying *NO* to political arguments!
> Whether there are more occurrences on more sites should have no relevance once
> the identifier has been assigned, just as other location selection criteria
> such
> as population are considered irrelevant once an identifier has been assigned.
>
> We have dropped posixrules and eliminated many other legacy rules and zones, we
> should in the course of time, eliminate all the alternate spellings, keeping
> only the base zone identifiers.
>
> Otherwise we appear to have given up any basis for resisting these political
> complaints and we should just add a link anytime anyone has any political
> objection to how we identify it.
> If this change is made, I would promptly expect growing demands for more
> political changes, as we have been shown to waver in the face of political
> demands unrelated to technical issues.
> There will be more demands to change or add official or remove unofficial zone
> identifiers on political bases.
>
> And for most English speakers the locations under discussion will for decades
> continue to be referred to as Ukraine, Crimea, Sebastopol, Kiev, etc.
> regardless
> of what the locals want to call it or have others call it.
> Few English speakers will recognize or assign any meaning to new names, unless
> both appear together regularly with explanations on common social and tabloid
> media web sites, which is unlikely as it not click bait.
> Those sites will continue to use the old spellings, as their primary focus is
> getting their readers attention, with words they recognize and could use.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
>
> On 2020-11-28 11:38, Paul Eggert wrote:
> > On 11/27/20 9:54 AM, Matt Johnson-Pint wrote:
> >
> >> how hard is it to add a link? ... We wouldn't even have to make the Kyiv
> >> spelling primary.
> >
> > This sounds like a good suggestion. We could add a link line as in the patch
> > below. This would be a test of the new feature of *forward*
> compatibility, not
> > *backward* compatibility, but it's pretty much the same thing as far as the
> > implementation goes so I'm not sure it's worth the hassle of creating a new
> > 'forward' file. Now that FreeBSD uses 'backward' along with everybody else,
> > putting this line in 'backward' means it should be supported by everybody
> who
> > cares about alternate names.
> >
> > I had already been meaning to move some other links to 'backward' for
> similar
> > reasons, but I figure we might as well do the tougher case first.
> >
> > I have not committed this patch, as the area is controversial.
> >
> > diff --git a/backward b/backward
> > index e13ae52..3327e58 100644
> > --- a/backward
> > +++ b/backward
> > @@ -1,9 +1,9 @@
> > -# tzdb links for backward compatibility
> > +# tzdb links for backward and forward compatibility
> >
> >
> > # This file is in the public domain, so clarified as of
> > # 2009-05-17 by Arthur David Olson.
> >
> >
> > -# This file provides links between current names for timezones
> > +# This section provides links between current names for timezones
> > # and their old names. Many names changed in late 1993.
> >
> >
> > # Link TARGET LINK-NAME
> > @@ -130,3 +130,9 @@ Link Etc/UTC UTC
> > Link Etc/UTC Universal
> > Link Europe/Moscow W-SU
> > Link Etc/UTC Zulu
> > +
> > +
> > +# This section is for forward compatibility, where the primary name is
> > +# likely to change if current trends in common English usage continue.
> > +
> > +Link Europe/Kiev Europe/Kyiv
>
More information about the tz
mailing list