[tz] Metazones in the tzdb (was Re: Why did you rename Russian zone name abbreviations)

[Random832]

On Thu, Nov 3, 2016, at 03:35, Guy Harris wrote:
> One way to do that might be to
> 
> 	1) have items either in the source files or in a separate file defining metazones and their tzdb-supplied abbreviations;
> 
> 	2) replace the FORMAT column with a METAZONE column and give the metazone name.

I strongly suspect that tzid/abbreviation pairs can be mapped directly
to metazones (i.e. there's no case where the same tzid and abbreviation
maps to two different metazones at different times). Or we could simply
ditch the abbreviations (a process we seem to already have started) and
put the metazone in the abbreviation field.

Or just maintain the tzid/time to metazone mapping source in a separate
file, either in the same format that CLDR does now or in some format
(whitespace-separated values?) that's easier to write a parser for. My
main point is that it should have the same release cycle as the rest of
tzdata, so that they won't fall out of sync, whether by creation of an
entirely new zone that CLDR doesn't know about, or moving one to a
different 'metazone'. This happens all the time and it only doesn't
cause problems because nobody actually uses the data; a status quo that
will not survive if we continue the course of removing abbreviations
from tzdata and insisting that people who need them switch to using the
CLDR.

> We'd also have version 4 of the compiled files; one possibility would be
> to append a count of metazones, a list of metazone names, and a table of
> metazone name table indices, indexed by the same value that's used as an
> index in the struct ttinfo table.  We could add an API that, for a given
> time_t value, returns the metazone name.  That could be used to look up
> data in the CLDR.

Incidentally, is there a CLDR mailing list? I feel like they should be a
part of this, since what I'm suggesting is essentially a transfer of
"ownership" of part of the data they currently maintain.