America/Edmonton and other zone naming issues

[Mark Davis]

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......
>
>
>
>
>
>
>