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

Paul Eggert eggert at twinsun.com
Sun Aug 9 06:27:53 UTC 1998

   From: Keith Moore <moore at cs.utk.edu>
   Date: Sat, 08 Aug 1998 22:16:01 -0400

   The Olson database has the (to me) undesirable property that there 
   are a lot of aliases.

Those aliases are mostly the result of the transition of old-style
Olson names (e.g. US/Pacific) to the new-style names
(e.g. America/Los_Angeles).  Any new standard could omit the old-style
names; this would alleviate the problem of aliases.  Some of those old
names are popular, though....

   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.

If we insist on ``really good solid authoritative information'', then
I'm afraid coverage will be limited.  Nobody keeps track of this stuff
authoritatively on a world-wide basis.  Nobody even keeps track of it
authoritatively for Indiana!

People have called for official bodies to keep track of this stuff
authoritatively -- the ISO, or the UN, or the IATA, or somebody.
It hasn't happened, and I don't think it likely to happen soon.

   (like places that use solar time)

Nobody uses solar time any more for civil time.  The last holdout was
Saudi Arabia; they converted to UTC+3 in 1950.

   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.

It's worse than that: the rules were not always uniform within the
same county.

   (I don't see a problem with the different parts of Indiana using
   /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate)

That doesn't work, because it mishandles time stamps before and after
transitions.  For example, Starke County, Indiana, switched from
CST/CDT to EST on 1991-10-27 (according to the Washington Post that
day).  So Starke County needs its own unique time zone history.  You
can't just say that Starke County is EST, because that would mishandle
time stamps before the switch; and you can't just say that Starke
County is CST/CDT, as that would mishandle timestamps after
the switch.

   How important is it for iCalendar timezones to work before 1998?

iCalendar should be able to handle the problems that occurred before
1998, because it's likely that similar problems will occur after 1998.

Besides, iCalendar should work for dates before 1998; I'd want to use
it that way myself.  Why limit it to future dates?

   I suppose we could use long/lat coordinates :)

That would work technically: e.g. instead of `/America/Los_Angeles'
you would use `/+340308-1181434' (with ISO 6709 notation for latitude
and longitude).  I also considered that, but decided against it for a
couple of reasons.  First, it's unfriendly.  Second, I was worried
that people might argue about the coordinates (where _is_ the center
of Los Angeles, exactly?).

   what defines a region, and how do people know what region they are

Ideally, a region would be a maximal set of points all sharing the
same time history.  A time history would start when standard time was
introduced, and would continue to the indefinite future.  As time
goes on, regions split and the number of regions grows.

The Olson database deviates from this ideal by making two concessions
to practicality.  First, it looks only at time histories since 1970
when determining regions; this greatly reduces the number of regions
(which would otherwise be in the thousands).  Second, regions never
cross current country boundaries; this is a concession to politics
that I would have rather avoided from a theoretical point of view, but
there were practical arguments for it (see below).

Ideally, regions would appear on a map, and someone has actually done
this for the Olson database; but I would urge that this not be made
part of the standard, for political reasons as well as technical ones.
Perhaps you could put the region boundaries into a non-normative annex
or whatever the IETF calls that sort of thing.

   The most populous city within a region still would't suffice to
   define names for all of Indiana's timezone histories.

Why not?  There must be at least one location for each unique time
history.  Just pick the most populous one.  Indiana has only 345
unique histories, according to Shanks (1990); each one has at least
one town in it.

   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.

The obvious names don't work once you take into account the fact that
cities can change time zones or time zone rules.  This happened, for
example, to Boise in 1974, to Anchorage in 1983, to Knox, IN in 1991,
and to Cancun last year; we can be pretty sure that it will happen
again soon to somebody.

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

This isn't a problem, since (as mentioned above) regions never cross
current country boundaries in the Olson database.

More information about the tz mailing list