Fw: Time Zone Names

Paul Eggert eggert at twinsun.com
Fri Oct 2 20:51:01 UTC 1998

   From: "Canaglobe International Inc." <mpereira at istar.ca>
   Date: Fri, 2 Oct 1998 12:49:40 -0400

   3. The ISO 3166 standard Parts 1 and 2 is not IT-enabled, the two letter
   alpha codes are not stable can and do change (The IANA and Internet domain
   names also has to address this problem but then underneath all the Internat
   names are the numeric codes used for the actual routing and addressing
   among the ISPs, IT-systems, etc.). The ISO 3166 the three digit numeric
   country code is the most stable and also unique.

True, but the 2-letter country codes are _much_ better known
(especially now that they're part of Internet domain names), and they
are much more common in most application areas served by POSIX and the
ISO C standard.  If you're going to use an ISO-based approach for
locations, then the 2-letter codes are clearly the way to go.

The 3-digit codes are not stable either, as locations change hands
(the breakup of the Soviet Union being a recent example of wholesale
reassignments).  Since complete stability is impossible, we have to
judge whether the 3-digit codes' slight increase in stability
compensates for the increased number of user (and/or programmer)
errors that are inevitable with numerical codes.  In my view, the
tradeoff is decisively in favor of the familiar alphabetic codes.

   P.S.I also agree that continent/citynames is not that useful. It neither
   provides the unambiguity nor uniques required for referencing purposes.

Actually, he current setup is unambiguous and the names are unique.
This is because there is a central registry of names.  You are arguing
for the substitution of a different central registry, one that is
blessed by the ISO.  Obviously this substitution will also work, and
it might be more politically acceptable; but it is not strictly
necessary to obtain uniqueness.

   1. Reference the ISO 3166 standard
   2. Always start with a Level one country code
   3. The a level 2 administrative subdivision code (e.g. state, province,
   lander, canton, etc)

Surely (3) is optional.  Pitcairn doesn't have provinces.  I assume
that (3) is in US-ASCII.

   4. The official name of the place according to the authoritative source,
   i.e. Wien and not Vienna or Vienne

For interoperability reasons, names should be encoded in US-ASCII.
Perhaps the standard could be extended to UTF-8 later, but I'm not
sure the world is ready for UTF-8 here; and besides, even UTF-8 can't
handle some place names.

   5. Optional the associated lat/long coordinate as assigned by the
   authoritative source.

In practice, there are many place names (even in the current tz
database) for which there is no authoritative source.  What is the
authoritative source for the name of the South Pole Station, for
example?  (The people who live in the station use different names at
different times, and would view a request for a canonical name with
some amusement.)  It will take the bureaucrats some time to catch up
to reality; in the meantime we need something that works now.

Therefore, (4) should be optional, and (5) should be a best guess in
case there's no authority.

   6. From a human interface needs and localization context, one would be free
   to provide different linguistic equivalent designations, i.e. "names"

I suggest that there be a standard way for one of these designations
to be an Olson-style name if one exists.  This will encourage
compatibility with existing practice, and will accommodate a gradual
transition to the new order of things.

More information about the tz mailing list