[tz] tzdb timezone names/identifiers and links

[Brian Inglis]

On 2019-02-27 23:03, Michael Douglass wrote:
> 
> On 2/28/19 00:45, Brian Inglis wrote:
>> On 2019-02-27 12:29, Michael Douglass wrote:
>>> On 2/26/19 17:17, Steve Allen wrote:
>>>> On Tue 2019-02-26T20:00:54+0000 Paul. oning hath writ:
>>>>> Once in a while it is suggested that all tzdb zones should be
>>>>> identified by random unique integers, or something like that.  I'm
>>>>> more and more inclined to think that's a good idea, because it would
>>>>> once and for all shut down this confusion.
>>>> This seems to be a proposal to
>>>> 1) Move the arguments to be Somebody Else's Problem, somewhere else.
>>> Yes - but also to provide a mechanism that makes it less of a problem
>>>> 2) Break a lot of existing interfaces to achieve that goal.
>>>> I cannot begin to calculate the cost of 2) but given the number of
>>>> downstream interfaces which use tzdb it seems likely larger than the
>>>> cost of tolerating the discussions on this list.
>>> There's an easy backwards compatibility mode:
>>> 1. have a uid for every zone
>>> 2. Create a set of data mapping that uid on to names that look like the current
>>> names
>>> 3. Provide a backwards compatability mode to take that file (or another named
>>> file) and put the names back
>>> For unchanged downstream software it looks exactly the same. However now we have
>>> disassociated the zones from the name. Downstream users are free to create their
>>> own files if they wish and we can also set about finding a owner for that name
>>> file (cldr perhaps?)
>> Changing tz ids from location names to numbers just means you need comments
>> describing the locations in the time zone to which it applies, and the arguments
>> become about the commentary instead of the ids, so you can never totally avoid
>> the issues.
> 
> That's possibly an issue but it's not a problem for this group.
> 
> The arguments are focused on the maintainers of that set of names. This group
> has made themselves the maintainers of a set of politically sensitive names and
> they are going to have to deal with these requests/demands/pleas until something
> is done to disassociate themselves from the names.
> 
> Yes - there are problems to be solved but if we don't make a start on what is
> technically a very simple problem we'll not get anywhere. We've made some pretty
> significant changes in calendaring over the last few years without the world
> coming to an end.
> 
> The first step is to disentangle the apolitical data from the names - at source.
> Downstream from that we have to figure out how to avoid significant upheaval
> and  don't think that's a major problem.
> 
> Beyond the nuisance aspect of all this the use of such names is a bar to using
> this information in a number of systems. It may not be the only issue but it is
> one we can deal with.

If we disassociate the ids from locations how does anyone make any sense or use
of the data?
You are pushing the problem down one level of indirection and dissociating
meaning from content.
The project has lasted and succeeded so long because it keeps to a few rules and
tries not to needlessly perturb the base data.
Feel free to fork the github experimental project data, try your ideas out, and
let us know how the uptake goes?

[Meaningful names help people comprehend - arbitrary identifiers are fine as
long as they are hidden for use purely internally by systems as long as people
never have to see or deal with them.
When people quote me numeric codes or ids for anything, I always tell them that
is meaningless to me, and ask them to explain in words.
Some years ago there were methodologies promoted to use only numeric ids for all
software components and variable names, and these were used in commercial
systems. Unfortunately as the commentary and documentation were as good quality
and well maintained as usual with commercial systems under time pressures,
systems might as well have been written in binary as far as comprehension and
maintenance went.]

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