Re: Contacts API

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.

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 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.

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

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.
>