- From: <richard.tibbett@orange-ftgroup.com>
- Date: Wed, 14 Apr 2010 17:54:08 +0200
- To: <public-device-apis@w3.org>
So we left the issue of how to represent TimezonedDate [ISSUE-81 and ACTION-129] relatively unresolved following a long e-mail discussion [1]. I'd like to move this forward on the list based around the two proposals currently provided. If anyone would like to suggest additional TimezonedDate representations then let us know. To summarise, the requirements for a TimezonedDate object are: - Dates and times MUST be settable to a specific timezone - e.g. to arrange a meeting across timezones based on a relative time from one participants timezone. - Dates and times MUST be capable of expressing Daylight Saving Rules in effect for the given time object. - Dates and times MUST allow 'floating' - e.g. to set an alarm to go off at 7am, regardless of which timezone I'm in. The two proposals follow: 1. RESTful TimezonedDate object (from [2]) WebIDL: ------- [NoInterfaceObject] interface TimezonedDate { attribute int year; attribute int month; attribute int day; attribute int? hours; attribute int? minutes; attribute int? seconds; attribute DOMString? tz; }; Usage: ------ // Floating TimezonedDate Object: { day: 26, month: 3, year: 2010, hours: 16, minutes: 58, // missing 'seconds' default to zero // missing or null 'tz' indicates that this object is not timezone-bound } // Web App may represent this information as provided. // Timezone-bound TimezonedDate Object: { day: 26, month: 3, year: 2010, hours: 16, // missing 'minutes' default to zero seconds: 30, tz: 'America/New_York' } // * Web App * has the responsibility to apply the provided 'tz' to the provided date and time information to calculate the applicable timezone offset (e.g. GMT-4 hours). Pros and Cons: -------------- Pro: A RESTful mapping is implicitly provided by this approach. Pro: Easy for implement (by a UA) Con: Web Apps are required to be timezone aware and provide timezone conversions at runtime (maybe [4] could help with that ;-)) 2. ECMA Date based TimezonedDate object (from [3]) WebIDL: ------- [ Constructor, Constructor(year, month, day, hours, minutes, seconds, timezoneID) ] interface TimezonedDate : Date { attribute DOMString? tz; }; ...with custom stringification behavior defined in the accompanying interface description: " Objects that implement the TimezonedDate interface must stringify as follows. By default the stringification of the object is the value provided by the underlying ECMA Date interface minus any timezone related timezone offset. If the 'tz' attribute is not null, the stringification of the object is the concatenation of the the response from the underlying ECMA Date interface minus any timezone indicator, the string " ", and the value of the applicable timezone offet as identified by the current 'tz' attribute in the form "GMT+HHMM[SS]" or "GMT-HHMM[SS]". If the 'tz' attribute is not null but cannot be identified against a known timezone identifier, the stringification of the object is the concatenation of the the response from the underlying ECMA Date interface minus any timezone indicator, the string " ", and the value of the current system's timezone offet as identified by the system's clock in the form "GMT+HHMM[SS]" or "GMT-HHMM[SS]". " Usage: ------ // Floating TimezonedDate Object: new TimezonedDate(2010,11,29,20,15,0); // stringification output: 'Mon Nov 29 2010 20:15:00' // Timezone-bound TimezonedDate Object: new TimezonedDate(2010,03,29,9,30,0,"America/New_York"); // stringification output: 'Mon Mar 29 2010 09:30:00 GMT-0400' // * Implementation * has the responsibility to apply the provided 'tz' to the provided date and time information to calculate the applicable timezone offset (e.g. GMT-4 hours). Pros and Cons: -------------- Pro: Implemented on top of the de-facto ECMA Date object. Pro: Easy-to-use. Web developers do not need to get in to the details of timezone conversions/rule management on the client-side. Con: No obvious RESTful mapping supplied by this interface. Con: ECMA Date is complex and will require far more stringification overrides than presented above (e.g. toUTCString(), toLocaleString(), etc will all need to be overridden with custom stringification behaviour). So these are the current approaches. ISSUE-81 also suggested that we might look in to creating a Web Dates specification. That may delay the roadmap for any DAP Calendar API but I'm not adverse to this idea - to inform other groups and recommendations that may need to tackle this issue in the future. Looking forward to your feedback. [1] http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0203.html [2] http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0229.html [3] http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0220.html [4] http://code.google.com/p/tzdata/ - Richard
Received on Wednesday, 14 April 2010 19:31:26 UTC