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

[Keith Moore]

>    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.

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