- From: Rich Tibbett <rich.tibbett@gmail.com>
- Date: Fri, 10 Dec 2010 13:04:32 +0100
- To: Christopher Hunt <huntc@internode.on.net>
- Cc: public-device-apis@w3.org
- Message-ID: <AANLkTinOHWoVevw98upVOWOQnfB6evycfAnwL1=sK8qa@mail.gmail.com>
On Fri, Dec 10, 2010 at 11:39 AM, Christopher Hunt <huntc@internode.on.net>wrote: > Hi there, > I just noticed something about the proposed Contacts API (1). With regards > to time zones, the current GMT offset is being provided. While I think that > can be of use, I think that it would be of better to supply the time zone in > Zoneinfo format (2). Zoneinfo is pretty much used by most Unix systems and > should be supportable by Browsers across all platforms IMHO. > > Perhaps even consider a Timezone object for Javascript based on the ICU > implementation (3). > Having time zone information available means that UTC offsets can be > calculated given any date/time. > We have identified this as a problem, especially wrt use within our proposed Calendar API. As such we are also developing a TimezonedDate object (though it's due for an update to be called TZDate) that accounts for timezone identifiers within Date objects: http://dev.w3.org/2009/dap/calendar/TimezonedDate.html I think this may cover your concerns. It's probably fair to say that the ECMA TC-39 Date object is limited in its usefulness at the moment. It would be much better if ECMA TC039 created a Calendar object based on the same structured used for the standard Java Calendar object: http://download.oracle.com/javase/6/docs/api/java/util/Calendar.html Having said that, it may not be such a critical issue within Contacts. Only the birthday and revision attributes use a Date object and the usage and storage of those attributes could be clarified IMO to factor out any timezone ambiguity (birthday should not include any time information, revision should be always be stored as a UTC value). However, when we start to deal with Calendaring events that can recur indefinitely and allow sharing those events between users across timezones this becomes critical. > > Other than that though, this seems like a great initiative. > Thanks for the feedback. If you have any further thoughts or proposals for handling timezone identifiers then please let us know. - Rich > > Kind regards, > Christopher Hunt > > (1) http://www.w3.org/TR/2010/WD-contacts-api-20101209/ > (2) http://en.wikipedia.org/wiki/Tz_database > (3) http://userguide.icu-project.org/datetime/timezone > >
Received on Friday, 10 December 2010 12:05:25 UTC