I agree with Gwillim Law; these are just identifiers. As far as I'm concerned, the <span style="font-style: italic;">best </span>strategy would be<br><ol><li>Never change remove or change what is in zone.tab.</li><li>Only add a new identifier to
zone.tab if a zone splits.</li><li>For such a new identifier, pick the largest city in the new zone according to some reasonable authority (eg<span> National Geographic Atlas of the World). Since it is just an identifier, don't worry about whether or not it includes metrop
</span>olitan areas or how; don't worry about whether the authority is the best possible one or not.</li><li>Make sure that last field is unique, eg don't have America/United_States/San_Jose if you have America/Costa_Rica/San_Jose. If it would not be unique, choose a different identifier for
zone.tab, or have some minor modification (San_Jose2)<br></li><li>Add aliases (links) where useful for clarification.</li></ol>Short of that, the current policies are reasonable, although it forces other parties (like CLDR) to impose additional measures for stability of identifiers.
<br><br>Mark<br><br><div><span class="gmail_quote">On 7/10/07, <b class="gmail_sendername">Paul Schauble</b> <<a href="mailto:Paul.Schauble@ticketmaster.com">Paul.Schauble@ticketmaster.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I suggested some time ago that zones should be named according to the<br>authority that declared the zone. This would often result in country<br>names or country name (subdivision). But it would also clearly identify<br>things like "Navajo Time" as such rather than lumping this in with
<br>"Denver".<br><br>I think this gives a more stable system that largest city. It completely<br>avoids the issues of what is a city. And it avoids changing zone names<br>when city population changes.<br><br> ++PLS
<br><br>-----Original Message-----<br>From: <a href="mailto:rlaw@nc.rr.com">rlaw@nc.rr.com</a> [mailto:<a href="mailto:rlaw@nc.rr.com">rlaw@nc.rr.com</a>]<br>Sent: Tuesday, July 10, 2007 11:38 AM<br>To: <a href="mailto:tz@lecserver.nci.nih.gov">
tz@lecserver.nci.nih.gov</a><br>Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi<br><br>> As the term city is ambiguous, the standard is ambiguous and<br>> inconsistent anyway.<br><br>How can we put an end to the incessant disputation over time zone
<br>identifiers? If we go by metropolitan area populations, someone will<br>say we should go by central city populations. If we use any criterion<br>that chooses Hanoi, someone will say Ho Chi Minh City is more important;
<br>but others will argue that the capital city is always more important.<br><br>We must bear in mind that these are only supposed to be identifiers.<br>Conceptually, we could be using WT/QAF just as well as Europe/Rome. It
<br>was merely for the convenience of developers that mnemonic names were<br>chosen. But it is the responsibility of a user interface, not of the tz<br>database, to translate the time zone identifiers into user-friendly<br>
names.<br><br>The volunteer maintainers of the tz database have plenty of work to do,<br>just to keep it up to date. If their job description is expanded to<br>include making sure that the definitions of cities are consistent,
<br>providing universally acceptable names and abbreviations for time zones,<br>or enabling localization by giving the translations of city, country,<br>and time zone names into an arbitrary number of languages, I believe
<br>that puts too much on their plate.<br><br>Presumably the CLDR addresses localization issues. Whoever maintains<br>the CLDR has undertaken responsibility for interpreting the identifiers<br>into human-readable form.<br>
<br>Identifiers should be stable, too. True, by using<br>backward-compatibility links, we can minimize the disruption caused by<br>changing an identifier. Still, any kind of change has its cost, and a<br>lot of the cost is hidden. We don't know how many people have used
<br>"Europe/Rome" somewhere in their code or nomenclature or documentation,<br>and would deem it necessary to change the string if the primary name of<br>that time zone changed to "Europe/Milan". (Of course, some changes are
<br>unavoidable, when time zones split.)<br><br>My suggestion would be to state boldly in the documentation, "Time zone<br>identifiers are arbitrary. Although they look as if they have a<br>geographic interpretation, there is no guarantee that they do, or will
<br>continue to in the future. They should not be displayed directly to end<br>users." Then, if possible, there should be some discussion of how to<br>display time zone information to users. If we get GIS files for time
<br>zone boundaries, that will be a big help. Maintaining the boundary<br>files would fall within the purview of the tz mailing list.<br><br>Gwillim Law<br></blockquote></div><br><br clear="all"><br>-- <br>Mark