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.
Actually, when I suggested that '/' be the introducer for global timezones, I had the Olsen database in mind, and have always assumed that we should start with a subset of that database. But if you're trying to define a standard for global timezone names, it makes sense to think carefully about them and see if you want to keep all of the Olsen timezone names. Some of them don't seem authoritative enough. The Olson database has the (to me) undesirable property that there are a lot of aliases. It seems like we would rather have "canonical" names when possible. And the Olsen database tries to define names for everything. It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. (like places that use solar time)
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.
I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. (somewhere I have a map of Indiana with different counties shaded according to their timezones) So you clearly can't force everything into clean and easily rememberd political subdivisions - you have to deviate somewhere. I still think it's convenient if *most* of the timezones are easily remembered. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate)
* 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.
How important is it for iCalendar timezones to work before 1998?
* 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.
Well, I suppose we could use long/lat coordinates :)
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.
Yes, but what defines a region, and how do people know what region they are in? (or for that matter, how do people know the most populous city in a region?) What timezone should I (in Knoxville, TN) use? Should I say /America/Cincinnati or /America/Atlanta or what? The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names.
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.
No argument there, and yet it would be nice if the names were obvious and guessable. It also seems like whenever there is a political border, we *know* there is a timezone fault-line where if a timezone changes on one side it will change independently of whatever is on the other side. There are of course other fault-lines: borders change, new borders are created, etc., but we can't anticipate everything. Finally, I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". (Note that the Pakistan/India conflict wouldn't have caused a problem anyway, because there was not a dispute about the names of the regions - only the borders of those regions.) Anyway, as I said earlier, I would defer to those with more experience. Keith