Time zone suggestions for draft-ietf-calsch-ical-08.txt

[Paul Eggert]

   From: Keith Moore <moore at cs.utk.edu>
   Date: Sat, 08 Aug 1998 17:49:54 -0400

   (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX
   is the iso 3166 country code and yyy is a political subdivision
   within that country.  In many cases just /XX suffices.  

Why not just stick with the names already in the Olson database,
preceded by `/' if necessary for the new standard?  The Olson names
are widely used existing practice, and I don't see a technical reason
to change them.

If the ``don't mess with success'' argument is not enough to convince
you, then let me explain why the Olson names are the way they are;
perhaps that will help.

I originally tried using an /XX/yyy style naming convention when I was
designing the naming scheme currently used by the Olson database, but
I discovered several problems with /XXX/yyy:

* Time zone rule boundaries are not well correlated with current
  political subdivisions.  For example, it is tempting to use `/US/IN'
  for US Eastern Standard Time without DST, as is currently practiced
  in most of Indiana, but that is incorrect, since part of Indiana
  _does_ observe DST.

* Indiana alone has hundreds of distinct time zone histories, only a
  few of which are in the Olson database due to its 1970 cutoff; as
  time goes on, more will need to be added to the Olson database.
  Even if we identified which subdivisions of Indiana would work for
  today's time zone histories (which would be a lot of work), the
  divisions would need to be further subdivided in the future, and
  this will cause compatibility problems.

* The names and boundaries of political subdivisions change too often.
  Even if we were to come up with names that work today, they would
  soon become obsolete.  It's more stable to choose names that depend
  as little as possible on politics.

* Using political subdivisions injects politics into what should be a
  technical discussion.  To some extent this is unavoidable, but it
  should be forestalled as much as possible by avoiding political
  subdivisions in the first place.

For these reasons, I used a naming convention that does not try to
identify the political boundaries of a time zone rule region.
Instead, I used the name of the most populous single location within
the region.  This method is be less controversial, more stable, and
more accurate than trying to name the entire region.

This naming regime survived the demise of the Soviet Union without
having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the
recent revolution in the Congo without having to worry about its
country-code change; and it survived the conflict between India and
Pakistan in Kashmir without having to suffer an embargo (unlike
Microsoft Windows, which unwisely put political boundaries into its
database).  It's not infallible; e.g. when Kuybyshev (the most
populous city in Russian UTC+4) changed its name back to Samara, the
database had to change its name too.  But in practice the current
Olson scheme has turned out to be more stable than any scheme based on
political subdivisions.