On Nov 2, 2016, at 9:55 PM, Random832 <random832@fastmail.com> wrote:
You have to take the tzid and an effective date to find out the "metazone", then the "metazone" knows what its abbreviations are. I've advocated in the past for tz files to identify the metazone of each transition because the CLDR should really not be responsible for keeping this up to date.
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. However, that might break code (other than zic, which we'd change) that reads the *source* files rather than the *compiled* files; if that's an issue, we might have to do something such as: give the new files names ending with ".tz" or some extension; have part of the process for building a release be running a program or script that takes the .tz files and, if the metazones are in a separate file, the metazone file, and generates old-style files with a FORMAT column. 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.