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@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?