What would be even better would be physical boundaries for each given zone. Right now, within multi-zone countries, the timezone database alone is insufficient to determine the behavior of any given city (or other location). Mark Oscar van Vlijmen wrote:

...

From: "Paul Schauble" <Paul.Schauble-ticketmaster.com>

...

In cases like this I really have to wonder about the custom of using the largest city.

To me, it makes much more sense to name the entity to which the change applies. Not just whatever city happens to be there. Naming the province, county, state, or whatever terms the changes applies to conveys more information.

The TZ software is Unix driven, so user friendlyness can't be an option ;-) It's a good thing that the engine itself has the least possible amount of zones. For maintainability it is a good thing that a zone has a readable name like America/Denver instead of for instance $937654-ACCF$.

But what about an actual human user? He/she would think: Boise, that's in Idaho (USA), so he would expect to find a zone like America/Idaho. But no, he has to use America/Denver, a city nowhere near Boise and even in another state. Speaking of Idaho, part of it is in Pacific Time. My guess is that more people are inclined to couple this to a name like Idaho-West than to Los_Angeles!

The problem is even worse for let's say Brazil. One could know that for instance Porto Alegre is in the province of Rio Grande do Sul in Brazil or Brasil. But to find the correct time you must realize that Porto Alegre is in America near Sao Paulo, a place not in America (as in USA) nor in the same province as Porto Alegre.

Europe versus Asia is another issue. Some countries are put into Asia, others into Europe, but a casual user can only think of e.g. Georgia. Instead he has to realize that it is in Asia and that the largest place is Tbilisi.

The TZ software has probably a fine mechanism for setting up userfriendly zone names. See the 'backward' file with all its Links. Virtually nothing has to change in the TZ engine, other than letting a single zone name (e.g. Georgia) being a valid zone name (instead of Asia/Tbilisi).

In October 1993 one discussion started around a new zone naming mechanism. A quote:

"Of course we should maintain links to traditional names like `Japan' and `US/Eastern' for backwards compatibility."

Hmmm......

Oscar van Vlijmen <ovv@hetnet.nl> writes:

He/she would think: Boise, that's in Idaho (USA), so he would expect to find a zone like America/Idaho. But no, he has to use America/Denver

That's not a good example. He should use America/Boise.

single zone name (e.g. Georgia) being a valid zone name (instead of Asia/Tbilisi).

That's another bad example. The vast majority of uses of the name "Georgia" in English refer to the USA state, not to the nation of Georgia.

The TZ software has probably a fine mechanism for setting up userfriendly zone names. See the 'backward' file with all its Links.

I'd rather not head that direction, since I don't want us to waste time arbitrating disputes over what's the best use of names like "Georgia". We have enough political problems as it is; let's not generate more of them. However, to answer the main point, the zone.tab file is supposed to help English-language users relate the Zone names (which are somewhat arbitrary) to a description of the affected region. The 'tzselect' shell script that comes with the tz database is one way to do this. People who prefer GUIs can easily substitute their own implementation that uses zone.tab. Here's a sample 'tzselect' interaction to show how this might work for your example user in Boise. $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) none - I want to specify the time zone using the Posix TZ format. #? 2 Please select a country. 1) Anguilla 18) Ecuador 35) Paraguay 2) Antigua & Barbuda 19) El Salvador 36) Peru 3) Argentina 20) French Guiana 37) Puerto Rico 4) Aruba 21) Greenland 38) St Kitts & Nevis 5) Bahamas 22) Grenada 39) St Lucia 6) Barbados 23) Guadeloupe 40) St Pierre & Miquelon 7) Belize 24) Guatemala 41) St Vincent 8) Bolivia 25) Guyana 42) Suriname 9) Brazil 26) Haiti 43) Trinidad & Tobago 10) Canada 27) Honduras 44) Turks & Caicos Is 11) Cayman Islands 28) Jamaica 45) United States 12) Chile 29) Martinique 46) Uruguay 13) Colombia 30) Mexico 47) Venezuela 14) Costa Rica 31) Montserrat 48) Virgin Islands (UK) 15) Cuba 32) Netherlands Antilles 49) Virgin Islands (US) 16) Dominica 33) Nicaragua 17) Dominican Republic 34) Panama #? 45 Please select one of the following time zone regions. 1) Eastern Time 2) Eastern Time - Michigan - most locations 3) Eastern Time - Kentucky - Louisville area 4) Eastern Time - Kentucky - Wayne County 5) Eastern Time - Indiana - most locations 6) Eastern Time - Indiana - Crawford County 7) Eastern Time - Indiana - Starke County 8) Eastern Time - Indiana - Switzerland County 9) Central Time 10) Central Time - Indiana - Daviess, Dubois, Knox, Martin, Perry & Pulaski 11) Central Time - Indiana - Pike County 12) Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties 13) Central Time - North Dakota - Oliver County 14) Central Time - North Dakota - Morton County (except Mandan area) 15) Mountain Time 16) Mountain Time - south Idaho & east Oregon 17) Mountain Time - Navajo 18) Mountain Standard Time - Arizona 19) Pacific Time 20) Alaska Time 21) Alaska Time - Alaska panhandle 22) Alaska Time - Alaska panhandle neck 23) Alaska Time - west Alaska 24) Aleutian Islands 25) Hawaii #? 16 The following information has been given: United States Mountain Time - south Idaho & east Oregon Therefore TZ='America/Boise' will be used. Local time is now: Wed Feb 8 14:34:44 MST 2006. Universal Time is now: Wed Feb 8 21:34:44 UTC 2006. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='America/Boise'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the ./tzselect command in shell scripts: America/Boise

On Thu, Feb 09, 2006 at 11:24:06PM +0100, Oscar van Vlijmen wrote:

The zone naming is not consistent.

I disagree.

Of course, some reasoning lies behind it, but just looking at the names: they are not of database quality. That's a hurdle to a non-TZ developer.

The database key (which is what the TZ zone names essentially are) should not define the UI used to choose regions. Would you be happier if we *did* call them names like "Z09432" instead of the partially mnemonic ones currently being used? That would certainly get rid of the mind-set that these keys should be usable for UI purposes... but it would also make it gratuitously more challenging to tell if one is referring to the right region. ("Is the time in Billings, Montana covered by Z09432 or Z09433?")

America/Boise refers to a county and a city in the USA.

The zone is *named* after the city. It is just a coincidence that the region encompassed by the zone happens to include a county of the same name.

America/Edmonton refers to a city not in the USA but in Canada.

"America" refers to the two "New World" continents, not any single country.

America/Sao_Paulo refers to a city in Brazil.

Which is in America (the continent pair). That folk from the US call themselves "Americans" is actually slightly insulting to those from other countries in the Americas. (Though I grant that "United Statesians" doesn't exactly roll off the tongue.)

America/Costa_Rica refers to a country.

Okay, I'll grant that that one is inconsistent. The comment in the zonetab file explains the reason: "There are too many San Joses elsewhere". I suppose the rule could be bent a different way by choosing the second-largest city, but the population of Alajuela is little more than half that of San Jose, so that too would be stretching the guidelines by a fair amount. Regardless, the basic choice is to either be completely (foolishly?) consistent and risk confusion about which San_Jose is meant, or to be inconsistent and choose something with better mnemonic value. (Perhaps America/Costa_Rica/San_Jose would have been a "meaningful" name that was more consistent with other entries.) --Ken Pizzini

From: Robert Elz

Rather than repeat all this discussion, again, and get everyone's opinion, again, (naming -of anything- is always an issue upon which everyone has an opinion) I would ask that if you don't like the current scheme, don't complain about it, instead come up with a detailed proposal for a new scheme.

I will not propose such a thing. The current scheme seems to work well enough and if it ain't broke..... nothing has to be proposed! The fact that there are developers who want to use the database by itself, has understandably a low priority to the TZ maintainers. Still, it doesn't hurt to review every now and then the qualities of the TZ distribution and to put it into the perspective of the competition. When TZ started, there was no internet competition. Now there is. Don't ask me where, since the definition of 'competition' is variable. But you'll catch the drift. I've concocted a complete list with possible alternative routes for zone names. It's nothing more than a demonstration model, with undoubtedly many errors and hair raising cruelties, but it's at least something tangible to look at. Don't expect that I or anyone else will do anything with this list after first publication. Alternative zone names are apparently not needed or wanted. But the list might serve some meditational need of some sorts. - Hm, I see, and where is this list of yours? Try: http://home-4.tiscali.nl/~t876506/ZonetabAlt.html (ca. 30 KB)