[tz] KyivNotKiev

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sun Nov 29 08:13:19 UTC 2020


On 2020-11-28 18:11, Philip Paeps wrote:
> On 2020-11-29 02:38:54 (+0800), 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.
> 
> If we're going to make a change ... we might as well do it in one go. Just do 
> the rename and put the old name in backward.  It seems obvious that that's the 
> way the data will look in the future anyway.
> 
> I can't see any technical benefits of trying out forward compatibility where 
> backward compatibility already covers the expected problems.

It makes the alternative available for those downstreams who pick it up and 
include it in their packages.
If you look across the various tzdata package builds, including embedded 
downstreams, you will find a wide variety of levels of compatibility provided, 
corresponding to most of the selection parameters provided in the build.
In some cases all backward links are dropped, possibly relying on CLDR and ICU 
for any compatability; in others a lot of legacy zone data is kept around, such 
that nothing that ever worked will ever produce different output, except perhaps 
for corrections, down to historical zone abbreviations; everything in between 
may be included, depending on distribution or project policy, maintainer intent 
and conscientiousness: the mode is likely to be the upstream tzdata defaults, 
perhaps with patches providing some (additional) deprecation notice period 
allowing other packages to be adapted, which may include the system time library 
routines.
In some databases, zone abbreviations as well as identifiers may be used as keys 
to the zones; in some data warehouses' time dimensions, many time properties can 
be used as keys, including zone (meta)data.

-- 
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.]



More information about the tz mailing list