time-zone-related comments on draft-ietf-calsch-csct-00.txt
eggert at twinsun.com
Fri Jan 3 02:44:44 UTC 1997
Here are some comments on the time-zone-related parts of your Internet Draft
``MIME Calendaring and Scheduling Content Type''
(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.
220.127.116.11 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
utc-offset = (_+_ / _-_) hour [[_:_] minute]
Following the above suggestions, the examples can be expressed
as follows in the extended notation:
18.104.22.168 Daylight Savings Rule
22.214.171.124 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).
More information about the tz