Chuck Soper <chucks@lmi.net> writes:
Many Olson TZIDs simply do not localize well. I believe that the Olson TZIDs were not designed with localization in mind.
I'm not sure what you mean here. TZIDs are merely identifiers for regions of the globe.
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
This is all in zone.tab now, for English only. The city or place name should be localized of course.
- sub-division (i.e. state, province, prefecture, or kingdom)
Often the TZID subdivisions are ad hoc; this reflects the ad hoc nature of time zone and DST political decisions. For the best TZ subdivision data I know of, please see Gwillim Law's Statoids <http://www.statoids.com/statoids.html>. Another source is Oscar van Vlijmen's Time zone boundaries for multizone countries <http://home-4.tiscali.nl/~t876506/Multizones.html>.
- 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)
This is a different table, one that is not currently addressed explicitly by the Olson database. There is not a 1-1 correspondence between time zone IDs and these names; it's a different relation. Also, there is widespread disagreement over what the names are, in any particular locale. Different Australians disagree about what the Australian English names are for their time zones, for example. I don't envy the job of people who would have to compile this information. (This is a polite way of saying that I'm skeptical about whether anybody's going to do it. :-)
- historic (yes/no)
An Olson Time zone identifier corresponds to a set of clocks that have used the same civil time since 1970, so I don't know what you mean by this attribute. Are you referring to discontinued identifiers?
additionally there could be columns to track if a particular time zone is within another time zone.
Olson TZIDs are either disjoint, or aliases. There are no parents. Perhaps this should be changed, but it would have to be designed carefully.
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.
Currently, to generate a time zone abbreviation, you need (1) an Olson TZID and (2) the UTC time stamp that you want the time zone abbreviation for. A single Olson TZID can map to many time zone abbreviations.
- 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?
iso3166.tab tracks all the current ISO 3166-1 identifiers. We haven't seen any need to worry about obsolete codes.
- Should XML or XLIFF be considered for meta data only?
That's an interchange issue, not a schema issue. The schema is more important. The source data can be stored in a simple text file, as now.
I'm interested to find about the status of this localization and to find a way to keep informed of the progress.
I suggest contacting Mark Davis.