time-zone-related comments on draft-ietf-calsch-sch-00.txt

[Paul Eggert]

Here are some comments on the time-zone-related parts of your Internet Draft
``MIME application/calendar Content Type''
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-sch-00.txt>
(November 1996).  Please let me know if you have any questions about
these comments, and I'd appreciate hearing about any updates to your draft.
The comments below are similar to comments I've made about
draft-ietf-calsch-csct-00.txt and draft-newman-datetime-00.txt, which
I can forward if you're interested.


3.2.3.19 TZID

	This section suggests that it is ``likely that we want an IANA
	registry of time zone/daylight rule names''.  I suggest that
	you consult the public domain time zone database maintained by
	Olson et al (<URL:ftp://elsie.nci.nih.gov/pub/>, updated
	regularly) for ideas about how such a registry should be
	maintained.  The Olson scheme is an upward-compatible extension
	of the Posix TZ string representation for time zone and
	daylight saving rules.  For example, in the Olson scheme, the
	label `America/Los_Angeles' identifies the complete UTC offset
	history for Los Angeles from to the introduction of standard
	time in 1883 to the indefinite future.  The Olson database is
	updated as governments change the rules, so the label
	`America/Los_Angeles' can be used by application programs
	without worrying about the details.

	It should be easy to convert the Olson database to any proposed
	IANA registry of time zone and daylight saving info.  Perhaps,
	as a first cut, you could start with the Olson database as the
	IANA registry.  You might contact the mailing list
	tz at elsie.nci.nih.gov if you are interested in using their work.

3.2.3.20 TZBias
3.2.3.21 TZDstBias
3.2.3.22 TZStdBias
3.2.3.23 TZStdTrans
3.2.3.24 TZDstTrans
3.3.1.2 Definitions
3.3.1.4 Recurring Event Date and Time Specification

	The underlying model in these sections is too simplistic.  It
	assumes that there is a ``standard time zone'' for the home
	calendar system, together with a single date and time for
	entering and exiting daylight saving time.  However, locations
	sometimes alter the UTC offset of standard time (e.g. Portugal
	and Sri Lanka in 1996).  Also, some locales have observed
	double daylight saving time for part of the summer (e.g. Britain
	in 1947), and TZStdBias does not suffice to represent this.

	The model should be fixed to allow an arbitrary sequence of UTC
	offset changes.  If necessary, each change could be labeled by
	a daylight saving flag (to say whether the resulting time is
	considered to be ``daylight saving''), and a string label
	(e.g. `EST') that can be internationalized (e.g. to `HNE' for
	French-speakers in Montreal).  This would be simpler and more
	accurate than the model in draft-ietf-calsch-sch-00.txt.

	I suggest that you consult the Olson database for ideas about
	how time zone and daylight saving information could be represented.

3.3.1.2 Definitions

	The proper term is ``daylight saving time'', not ``daylight
	savings time'' (at least, that is what the OED and the Random
	House Unabridged Dictionary prefer).

	``Pacific Daylight Savings Time'' should be ``Pacific Daylight Time''.

3.3.1.4 Recurring Event Date and Time Specification

	This section does not address the problem of ``impossible
	times'' (e.g. `1996-04-07 02:30:00', which does not denote a
	valid local time in Los Angeles) or ``ambiguous times'' (e.g.
	`1996-10-27 01:30:00', which denotes two distinct valid local
	times in Los Angeles).  When a time is converted from some
	locale to UTC, it may be found to be impossible or ambiguous;
	in that case, what should a scheduling application do?