W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2010

[calendar] TimezonedDate

From: <richard.tibbett@orange-ftgroup.com>
Date: Wed, 14 Apr 2010 17:54:08 +0200
Message-ID: <355A518BC0575547B2A3D6773AAF8EEFB3016B@ftrdmel1>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT