Over a month ago Mark Davis posted an email that mentioned issues related to translations of time zone IDs provided by the common locale data repository project (CLDR). I'm interested to find about the status of this localization and to find a way to keep informed of the progress. The initial email discussion was somewhat lengthy and I'm sure that I did not digest all the points mentioned. The beginning of the CLDR proposal explains the current mechanism for localizing Olson Time Zone Identifiers (Olson TZIDs). And in the tz code directory, the rules for naming Olson TZIDs are in the Theory file. Many Olson TZIDs simply do not localize well. I believe that the Olson TZIDs were not designed with localization in mind. I suggest a zoneMeta.tab file (very similar to zone.tab) be created for the propose of facilitating localization. Such a file could include the following columns: - ISO 3166-1 - latitude/longitude (from zone.tab) - Olson TZID - city or place name - sub-division (i.e. state, province, prefecture, or kingdom) - time zone name, general (e.g. Eastern Time) - time zone name, specific if is exists (e.g. Eastern Standard Time - Indiana - most locations) - time zone name, std (e.g. Eastern Standard Time) - time zone name, dst (e.g. Eastern Daylight Saving Time) - historic (yes/no) - attributes (major, minor, etc.) Is Center, North Dakota minor? (perhaps historical and attributes could be combined?) - geographical comments (entire country or ISO subdivision codes?) - revision notes (always the last column) additionally there could be columns to track if a particular time zone is within another time zone. - tz level (e.g. Denver == 0, Arizona == 1) - parent Olson TZID (e.g. Arizona's parent is Denver) *** It's important that this information is maintained in the time zone database. The maintainers of the database should be the ones to determine or declare if a particular time zone is modern, historical, major, minor, or has other attributes. I also think that a meta data file for time zone abbreviations would be useful. Many abbreviations are important and widely used while others are invented by the maintainers for convenience. Currently, time zone abbreviations are not unique (e.g. EST) and need to be associated with both an ISO 3166-1 code and an Olson TZID. A abbrMeta.tab file could contain the following columns: - ISO 3166-1 - OlsonTZID - time zone abbr - regular (e.g. PT for Pacific Time) - time zone abbr - std (e.g. PST for Pacific Standard Time) - time zone abbr - dst (e.g. PDT for Pacific Daylight Saving Time) - time zone name - regular (e.g. Pacific Time for PT) - time zone name - std (e.g. Pacific Standard Time for PST) - time zone name - dst (e.g. Pacific Daylight Saving Time for PDT) - historic (yes/no) - abbr valid or in use (yes/no) - comments - revision notes A unique time zone abbreviation ID could could eliminate the need to have time zone names in both the abbrMeta.tab and zoneMeta.tab files. The zoneMeta.tab file could contain unique time zone abbreviation IDs that refer to the abbrMeta.tab file. Perhaps, simply appending the abbreviation to the ISO 3166-1 code. Pacific Standard Time for the US could be US_PDT. The purpose of these meta data files would be to provide English readable time zone information (more comprehensive than zone.tab) and to facilitate localization. These files could be added to the data directory and clearly noted that they are a work in progress. If this or a similar approach is taken the validity of these data will evolve over time. Questions: - Should the tz database attempt to maintain or track ISO 3166-1 codes that are either obsolete or do not have an associated time zone? - Should XML or XLIFF be considered for meta data only? This would allow future support for local city, sub-division, and time zone names utilizing Unicode. A local name would be in the country's own language (and there might be secondary local names for countries with more than one language). I expect to be very busy for the next couple of weeks, but I'm interested to find out if my comments are useful. Chuck