[tz] Reason for removal of several TZ

[Brian Inglis]

On 2017-12-04 15:13, Clive D.W. Feather wrote:
> Brian Inglis said:
>>> I'd suggest a first step would be to provide a unique - reasonably short - 
>>> opaque id for each definition. That allows us to build out a localization 
>>> framework around it.
>> Feel free to write a script to mv each path to its lat/long (and create a link
>> to its previous name(s) for compatibility) as that is the only other reasonably
>> stable property of the tz db usable as a name and a l14n reference: otherwise
>> people will assume the id will always be around and mean something, as with zone
>> names, country codes, tz abbrs, etc.
> What's wrong with just labelling the present zones with randomly allocated
> letter-digit-letter codes? That gives us 6760 codes that don't look like
> city names or commonly-used abbreviations. We can then reserve
> letter-letter-digit for future expansion and digit-letter-letter for
> private use.

Arbitrary codes are just another level of indirection, and should only be used
for internal machine representations to which is attached some arbitrary
descriptive content with no semantic value, which may be arbitrarily changed to
some other descriptive value by a user, not anything to be exposed to, used, or
comprehended by a human.

If they are fixed values, as they must be to support l14n, users and programmers
will presume the semantics of whatever is represented by the id, as they have
with tz abbreviation labels, so you get similar issues.

> As soon as people know it's lat/long, they'll try to map it to cities and
> the same arguments will start again.

The issues in this group seem to focus on countries, cities, and names.

Using lat/long avoids those issues, and is an existing semantic property of a
zone, about which we rarely have questions, and even fewer corrections.

Theory could instead expound upon selection of observatories, universities,
clock towers, settlements, and municipalities chosen to represent a zone, and
their coordinates.

They can map it to cities or whatever they wish to support in their locales, but
that will be their or CLDR's problem, not an issue for this list, as /even/
David Patte agrees ;^>

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