[tz] tzdb timezone names/identifiers and links
mikeadouglass at gmail.com
Thu Feb 28 06:03:09 UTC 2019
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
>> 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.
More information about the tz