- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 24 Mar 2010 16:00:02 +0100
- To: richard.tibbett@orange-ftgroup.com
- Cc: public-device-apis@w3.org
Le mercredi 24 mars 2010 à 15:33 +0100, richard.tibbett@orange-ftgroup.com a écrit : > The CalendarProperties interface will be changed to the following: > [NoInterfaceObject] > interface CalendarEventProperties { > ... > attribute Date? start; > attribute Date? end; > ... > attribute DOMString? tz; > ... > } > > - '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) 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 Dom > [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
Received on Wednesday, 24 March 2010 15:00:14 UTC