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

[Paul Eggert]

Here are some comments on the time-zone-related parts of your Internet Draft
``MIME Calendaring and Scheduling Content Type''
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-csct-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-sch-00.txt and draft-newman-datetime-00.txt, which
I can forward if you're interested.

3.1.3.7 Date and Time

	The examples do not match the grammar in the use of the character
	`T' to separate date and time.  The grammar specifies date followed
	by time; the examples use `T'.  The grammar is to be preferred here.
	Common practice (allowed by ISO 8601) is to write the date followed
	by a space followed by time; this is easier for humans to read.

	ISO 8601 allows fractions to be preceded by `.' instead of `,';
	this should be allowed by the grammar.

	The grammar allows a utc-offset without a sign; this should be
	fixed, as utc-offsets always have a sign in ISO 8601.  Also,
	common practice (allowed by ISO 8601) is to omit the `:' and
	minutes of a UTC offset when minutes are zero.  Here is a
	proposed patch:

		utc-offset = (_+_ / _-_) hour [[_:_] minute]

	Following the above suggestions, the examples can be expressed
	as follows in the extended notation:

		1996-04-15 08:30:00-05
		1996-04-15 13:30:00Z

3.1.5.2 Daylight Savings Rule
3.1.5.5 Time Zone

	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 two transitions do 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).

	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 time zone and daylight
	saving information could be represented.  For example, you
	could pass labels that identify time zone and daylight saving
	rules.  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.

	By the way, 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).