From: Keith Moore <moore@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.