Re: Contacts API

On 16/12/2010, at 9:29 AM, Rich Tibbett wrote:

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

Outlook and iCal get around this by referring to a time zone using X-WR-TIMEZONE (1). There is also the VTIMEZONE object for iCalendar (2). My take on VTIMEZONE is that it is not sophisticated enough to express the complex world of time zones and that referring to a time zone using a ZoneInfo descriptor is more robust (let the browser take on implementing and supporting ZoneInfo). With all approaches, time should be specified with its relationship to UTC.

(1) http://en.wikipedia.org/wiki/ICalendar#Other_component_types
(2) http://tools.ietf.org/html/rfc5545

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

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

What may also be of interest is that I'm presently developing a Java implementation of the ZoneInfo parser (using ANTLR) and a Java TimeZone facade into ZoneInfo data. This parser (given ANTLR) can readily be extended to drop other language targets including JavaScript and C++. I realise that ICU also provides ZoneInfo compatibility (3), but I needed a time zone database that could be updated dynamically. The ICU approach (which Java 6 wraps itself around) relies upon the zone info database being updated statically.

I'll shortly release my work to the community as open source. Perhaps it would be helpful here in determining what a Javascript TimeZone object should look like. Meanwhile please find attached the class diagram I'm working to.

(3) http://site.icu-project.org/

Kind regards,
Christopher