Localization Facilitation

Chuck Soper chucks at lmi.net
Fri Sep 10 19:17:53 UTC 2004

At 1:33 PM -0700 9/9/04, Paul Eggert wrote:
>Chuck Soper <chucks at 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,
>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, 

Perhaps, the Open Geospatial Consortium would be interested in 
helping add region boundaries to the tz database?
They clearly state: "Our core mission is to deliver spatial interface 
specifications that are openly available for global use."


More information about the tz mailing list