Vietnam: Saigon is deprecated, should use capital Hanoi

[Mark Davis]

I agree with Gwillim Law; these are just identifiers. As far as I'm
concerned, the best strategy would be

   1. Never change remove or change what is in zone.tab.
   2. Only add a new identifier to zone.tab if a zone splits.
   3. For such a new identifier, pick the largest city in the new zone
   according to some reasonable authority (eg National Geographic Atlas
   of the World). Since it is just an identifier, don't worry about whether or
   not it includes metropolitan areas or how; don't worry about whether
   the authority is the best possible one or not.
   4. 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)
   5. Add aliases (links) where useful for clarification.

Short of that, the current policies are reasonable, although it forces other
parties (like CLDR) to impose additional measures for stability of
identifiers.

Mark

On 7/10/07, Paul Schauble <Paul.Schauble at ticketmaster.com> wrote:
>
> I suggested some time ago that zones should be named according to the
> authority that declared the zone. This would often result in country
> names or country name (subdivision). But it would also clearly identify
> things like "Navajo Time" as such rather than lumping this in with
> "Denver".
>
> I think this gives a more stable system that largest city. It completely
> avoids the issues of what is a city. And it avoids changing zone names
> when city population changes.
>
>     ++PLS
>
> -----Original Message-----
> From: rlaw at nc.rr.com [mailto:rlaw at nc.rr.com]
> Sent: Tuesday, July 10, 2007 11:38 AM
> To: tz at lecserver.nci.nih.gov
> Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi
>
> > As the term city is ambiguous, the standard is ambiguous and
> > inconsistent anyway.
>
> How can we put an end to the incessant disputation over time zone
> identifiers?  If we go by metropolitan area populations, someone will
> say we should go by central city populations.  If we use any criterion
> that chooses Hanoi, someone will say Ho Chi Minh City is more important;
> but others will argue that the capital city is always more important.
>
> We must bear in mind that these are only supposed to be identifiers.
> Conceptually, we could be using WT/QAF just as well as Europe/Rome.  It
> was merely for the convenience of developers that mnemonic names were
> chosen.  But it is the responsibility of a user interface, not of the tz
> database, to translate the time zone identifiers into user-friendly
> names.
>
> The volunteer maintainers of the tz database have plenty of work to do,
> just to keep it up to date.  If their job description is expanded to
> include making sure that the definitions of cities are consistent,
> providing universally acceptable names and abbreviations for time zones,
> or enabling localization by giving the translations of city, country,
> and time zone names into an arbitrary number of languages, I believe
> that puts too much on their plate.
>
> Presumably the CLDR addresses localization issues.  Whoever maintains
> the CLDR has undertaken responsibility for interpreting the identifiers
> into human-readable form.
>
> Identifiers should be stable, too.  True, by using
> backward-compatibility links, we can minimize the disruption caused by
> changing an identifier.  Still, any kind of change has its cost, and a
> lot of the cost is hidden.  We don't know how many people have used
> "Europe/Rome" somewhere in their code or nomenclature or documentation,
> and would deem it necessary to change the string if the primary name of
> that time zone changed to "Europe/Milan".  (Of course, some changes are
> unavoidable, when time zones split.)
>
> My suggestion would be to state boldly in the documentation, "Time zone
> identifiers are arbitrary.  Although they look as if they have a
> geographic interpretation, there is no guarantee that they do, or will
> continue to in the future.  They should not be displayed directly to end
> users."  Then, if possible, there should be some discussion of how to
> display time zone information to users.  If we get GIS files for time
> zone boundaries, that will be a big help.  Maintaining the boundary
> files would fall within the purview of the tz mailing list.
>
> Gwillim Law
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20070710/4b942b11/attachment-0001.html