Thank you for responding to my long email and I'm sorry for my delayed response. I think that my original post went too far towards addressing localization issues. I will scale back that suggestion and try to explain my rationale. When an operating system organization, a software developer, or perhaps, the common locale data repository project (CLDR) needs to display time zone location names (based on zone info files) in English or localized to another language that zone.tab and other files in tzdata is generally the starting point. Many TZIDs do not (nor should they) express the city and state/province for the TZID. I know of at least 48 such TZIDs. I suggest that two new columns be added to zone.tab, location (city) and sub-division (state/province). The sub-division would be for the city not the entire time zone region. For example, Illinois for America/Chicago. For many or most TZIDs the sub-division field may be blank. I'm fairly sure that most or all of the information to do this is already in the tzdata files. I believe that the task of assembling English readable tz location names that correspond with TZIDs for the purpose of display (English or localized) has been done many times. Each time this task is done it would be reasonable to expect slightly different results. Having these two new columns, location and sub-division, would add consistency and improve maintenance of tz location names. Also, having the columns would prevent the task from continually being repeated by different people and organizations. On my Unix-based system the tz location name for Chicago is "Chicago" not "Chicago, Illinois". I think this is because the state/province information is not easily accessible from the zone.tab file. This is my suggestion. I'm not sure there is interest in this suggestion, but I at least wanted to convey what I was thinking. Chuck I have a few additional comments below. At 10:05 PM -0700 9/2/04, Paul Eggert wrote:
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 agree.
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>.
By sub-division, I meant for the tz location city not the entire time zone region. I am also interested in time zone regions and I appreciate these references.
- 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. :-)
I would like to try this for a project that I am working on, but I suspect it will be difficult.
- 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?
My idea of labeling historic (and modern) time zones comes from the following text I read in the CLDR Time Zone Localization proposal: "A lot of people just don't care about historic differences." While I do agree with the statement, I am not sure if there are clear definitions for historic and modern time zones. Perhaps, the entire country of Argentina is a historic time zone. :-) In any case, my comments about historic/modern time zones should be directed to the CLDR.
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.
I like the idea of tracking parent/child relationship for time zones, yet I'm not sure how important it is.
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.
Thanks for the clarification. I need to look at this more closely.
- 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.
I agree. I think I suggested this because YU and BV were mentioned in the original Time Zone Localization discussion related to CLDR.
- 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.
This makes sense to me. (I was in a localization mindset.)
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.