Vietnam: Saigon is deprecated, should use capital Hanoi

[Paul Schauble]

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