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

Re: Contacts API

From: Rich Tibbett <rich.tibbett@gmail.com>
Date: Wed, 15 Dec 2010 23:29:59 +0100
Message-ID: <AANLkTi=tJUK-Dh1ZCpcTh8YKNC=TeezEbBZxz=dXOOkV@mail.gmail.com>
To: Christopher Hunt <huntc@internode.on.net>
Cc: public-device-apis@w3.org, Dominique Hazael-Massieux <dom@w3.org>
On Fri, Dec 10, 2010 at 11:55 PM, Christopher Hunt

> Hi Rich,
> The common view is that Timezone is a separate concept to Date; a Date's
> time value is always normalised to UTC. Given a Date you can resolve the UTC
> offset by passing it to a Timezone object whereupon rules are applied.

That does sound like a reasonable approach. However with recurring events
(in the Calendar API) we need a way to bind these two objects together at
storage. If we only store the Date value, skip ahead 6 months on a recurring
event, and pass in the Timezone object then things start to go awry.

> I would look to deprecate the local time methods of the Date object and
> introduce Timezone - even better if the ICU or Java interfaces could be
> modelled on as they are for Java and Cocoa (1) (2).

I'd like the ECMA TC-39 group to work on changes to the Date object or
introduce a Calendar object.

Chairs, have any inquiries been made in that direction?

> I think Christopher was alluding to the "timezone" attribute of the Contact
> interface:
> http://www.w3.org/TR/2010/WD-contacts-api-20101209/#widl-Contact-timezone
> I was indeed referring to this.


The confusion is in this attribute's description. This attribute will be
changed to indicate that both timezone offsets and zoneinfo timezone
identifiers are allowed in this attribute.

> Thanks for entertaining these thoughts. I'm happy to play a more
> significant role here if you think it is worthwhile (3) (4).

That sounds interesting. We're particularly looking for input around the
Dates and Timezones and the feedback you've provided is very helpful.

- Rich

> Kind regards,
> Christopher
> (1) http://icu-project.org/apiref/icu4j/
> (2)
> http://download.oracle.com/javase/1.4.2/docs/api/java/util/TimeZone.html
> (3) http://christopherhunt-software.blogspot.com/
> (4) http://au.linkedin.com/pub/christopher-hunt/0/108/a54
> On 10/12/2010, at 11:04 PM, Rich Tibbett wrote:
> 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.
Received on Wednesday, 15 December 2010 22:30:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:47 UTC