RE: ACTION-129: Expressing timezones in the Calendar API

Hi Dom, Philip,

On 24-Mar-10 21:37, Philip Gladstone wrote:
> 
> On 24-Mar-10 11:00, Dominique Hazael-Massieux wrote:
> >
> > Thanks for looking into this! 2 comments:
> > - I think we should choose either the Olson identifier, or the URI 
> > one, but not mix them both up in a single field; I would personally 
> > suggest using the Olson identifier for v1
> > - I'm slightly uncomfortable with binding the whole event to a 
> > timezone rather than to the specific dates that are defined in it 
> > (start, end, reminders, and recurrence limits); use cases 
> that require 
> > binding to the dates rather than events are somewhat 
> convoluted, but 
> > it seems like bad design to separate a datetime from its 
> timezone in 
> > general. Also, since we mentioned other cases where we would need a 
> > "timezoned" datetime (e.g. reception times for messages), I still 
> > think we should work on TimezoneDate object rather than 
> adding this on 
> > the side for events
>  
> There are certainly calendar events that make sense with 
> differing starting and ending timezones. For example, United 
> 177 leaves Boston at
> 11:15 America/New_York and arrives in San Francisco at 15:00 
> America/Los_Angeles -- and this is how the flight will appear 
> in your reservation. This is the 'obvious' form of the 
> calendar event that corresponds to my flight.
> 
> Thus I support having a timezoned datetime object rather than 
> trying to split out the timezone into a separate field.
> 

Thanks for the feedback and the good use cases.

Picking up from the previous proposal (Olson timezone identifiers for
expressing timezones [1]) we can define a TimezonedDate interface as
follows:

[NoInterfaceObject]
interface TimezonedDate {
	attribute Date value;
	attribute DOMString? tz;
}

The following correction is noted to the CalendarEventProperties
interface (superseeds previous example on this thread):

[NoInterfaceProperties]
interface CalendarEventProperties {
	...
	[PutForwards=value]
	readonly attribute TimezonedDate start;
	[PutForwards=value]
	readonly attribute TimezonedDate end;
	...
}

where:

- 'tz' can be an Olson timezone identifier [1] (e.g. 'Asia/Seoul')

If no 'tz' object is provided or 'tz' is null, the TimezonedDate 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 in
[1]).

PutForwards is implemented on TimezonedDate objects as specified in the
WebIDL spec [2].



I have considered the i18n implications of this approach. IOlson
Identifier could map to a Lunar-based implementation of the Olson TZ
data. No such database exists currently AFAIK but the abstraction to
Olson identifiers may be sufficient for translation to different
calendaring systems. Feedback on this is welcome.

Further on i18n, the TimezonedDate interface definition may wish to
include the proposal in [3] for multiple calendar systems support - with
the restriction on recurring non-Gregorian events detailed therein still
being applicable.



[1] http://www.w3.org/TR/timezone/#tzinfo

[2] http://www.w3.org/TR/WebIDL/#PutForwards

[3]
http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0183.html


- Richard


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

Received on Thursday, 25 March 2010 10:45:49 UTC