[tz] tzdb timezone names/identifiers and links

Martin Burnicki martin.burnicki at meinberg.de
Fri Mar 1 09:17:49 UTC 2019

Brian Inglis wrote:
> 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.

On the one hand I sometimes read on this ML that the basic names used
for the zones should only be taken as IDs, and not be displayed directly.

On the other hand a pure numeric ID is hard to handle even for
developers, so what if we used a combination of numeric and readable
string as ID?

This would make it more obvious to "external" developers that the IDs
are not meant to be directly displayed, and eventually that would let
them have a look at the theory file. I bet that many developers who are
not very familiar with this stuff don't do this because they *assume*
that the ID strings can be used directly.

> The project has lasted and succeeded so long because it keeps to a few rules and
> tries not to needlessly perturb the base data.

This doesn't necessarily mean that there is no room for improvement. If
you have a look at the whole picture and not only at the pure database
(which is undoubtedly very precious) then you see there is not only
little confusion on how to use it properly.

Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

More information about the tz mailing list