ACTION-129: Expressing timezones in the Calendar API

At the F2F I took an action to explore the best way to express date/time
objects and timezones in the Calendar API. I am including some thoughts
and a proposal here for group review.

>From previous discussions the requirements for date/time objects seem to
be as follows:

- Dates and times MUST be settable to a specific timezone - e.g. to
arrange a meeting across timezones
- Dates and times MUST be capable of expressing Daylight Saving Rules in
effect for a given event
- Dates and times MUST allow 'floating' - e.g. to set an alarm to go off
at 7am, regardless of which timezone I'm in.

vCard v4 and iCalendar take different approaches to specifying
timezones. 

- vCard v4, the proposal is to use a DOMString identifier that can be
used to denote the timezone [1].

- iCalendar takes a more verbose approach, allowing a whole set of
timezone rules (e.g. accounting for daylight saving time) to be passed
within a given VTIMEZONE element [2].

The choice is between refering to abstract timezone identifiers or to be
verbose about timezone information in the API itself. Of these two
choices, I see using identifiers as being a simpler way of expressing
timezones - web developers do not need to get in to the gritty details
of finding, parsing and including timezone rules in to events
themselves. Developers only need to include a timezone identifier from
which any timezone rules can be inferred from other implementations as
required.

At the F2F we also agreed to change all date/time representations in the
Calendar API to standard Date objects. 

The CalendarProperties interface will be changed to the following:

[NoInterfaceObject]
interface CalendarEventProperties {
	...
	attribute Date? start;
	attribute Date? end;
	...
	attribute DOMString? tz;
	...
}

where:

- 'start' and 'end' become standard Date objects
- 'tz' can be either:
	- an Olson timezone identifier [3] (e.g. 'America/Los_Angeles')
	- a CalConnect Timezone URI identifier [4] (still under
development but included for future proofing the API)

If no 'tz' object is provided or 'tz' is null, the event should be
considered 'floating' (i.e. 7am regardless of location). If the 'tz'
value is not a valid/recognized identifier the 'tz' attribute MUST
default to 'UTC' (where 'UTC' is a valid Olson Timezone Identifier).

All Date attributes included in any 'recurrence' objects will also be
bound to the identifier provided in the root 'tz' attribute.


Does anyone have any further requirements or objections to including
dates and timezones in this way?


[1] http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-10.txt (issue
tracker for vCard 4 shows discussion that resulting in this decision:
http://www.vcarddav.org/issues.xhtml#187)

[2] http://tools.ietf.org/html/rfc2445#section-4.6.5

[3] http://www.twinsun.com/tz/tz-link.htm (would be referenced in a W3C
spec in the same way as in RFC4833:
http://tools.ietf.org/html/rfc4833#ref-7)

[4] http://www.calconnect.org/tc-timezone.shtml



- Richard

Received on Wednesday, 24 March 2010 14:40:44 UTC