At 1:33 PM -0700 9/9/04, Paul Eggert wrote:
Chuck Soper <chucks@lmi.net> writes:
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.
But America/Chicago identifies a fairly large chunk of the United States, including Iowa, Missouri, most of (but not all of) Kansas, etc.
The main idea behind the "America/Chicago" and the current latitude/longitude is to identify a single point in the region, a point that will continue to be identified if the region splits (an event that occurs from time to time). The latitude/longitude is a quite-inadequate substitute for what is really needed (namely, the entire region boundary), but it's the best we've got right now. I worry that adding a column with data like "Illinois" would be a step in the wrong direction, and would cause more confusion than it would cure, since "Illinois" is an attribute of Chicago, and is not a direct attribute of the America/Chicago TZID.
I tend to think that: - a populous geographic point within a time zone region, and - a description of the entire time zone region are both useful. When I want to know what time what is in Sydney, the display name "Sydney, Australia" is more understandable to me than "Eastern Standard Time" or "Eastern Summer Time". Yet, if I lived in Australia then Eastern Time would be more understandable. I live near San Francisco, California. If someone talks about the time zone for Los Angeles it sounds strange, but if they say, "Pacific Time", then it makes sense. I believe that the understandability of a time zone display name (Los Angeles or Pacific Time) is dependent on where you are from. Even if the time zone boundaries were available there would still be a need for a display name such as "Chicago", "Chicago, Illinois", "Central Daylight Time", or "Chicago - Central Time". I don't think that adding a column with data like "Illinois" wouldn't cause more confusion, it would just maintain the save level of confusion. :-) On the other hand, adding a couple columns to zone.tab would probably not provide any immediate benefit to anyone. And it is work that would take time. Thanks for listening to my feedback.
What we really need are the region boundaries (ideally hooked up to GPS :-), or some data that will let us derive the region boundaries from other databases. The current "comments" column is an informal attempt in that direction, and I'd rather focus our efforts there.
I like the idea of heading in the direction of having the actual region boundaries. About a year ago, using ESRI software, I thoroughly looked manifold.net's World Time Zones Map. At that time it was a little out of date. It looked like it would be difficult to maintain. I'm glad that Manifold made it available. The current "comments" column contains various data. I think it would help if this was a little more formal. A "region" column with a specific format might be an answer, yet I think there would probably be a lot of issues (standardization of codes such as ISO or FIPS, etc.). Perhaps, the Open Geospatial Consortium would be interested in helping add region boundaries to the tz database? http://www.opengeospatial.org/about/?page=vision They clearly state: "Our core mission is to deliver spatial interface specifications that are openly available for global use." Chuck