Re: Contacts API

On Fri, Dec 10, 2010 at 11:55 PM, Christopher Hunt
<huntc@internode.on.net>wrote:

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

Right.

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