[uf-discuss] hCalendar Implementation

[Ryan King]

On Jan 13, 2006, at 12:28 PM, Tim White wrote:

> --- Ryan King <ryan at technorati.com> wrote:
>
>> You could probably just markup one of the times in each section,
>> since they are logically equivalent.
>>
>> -ryan
>
> I had thought of:
>
> <div class="vevent">
> <h4>Date: <abbr class="dtstart" title="2005-01-23T16:00-5:00">Monday,
> January 23, 2006</abbr></h4>
> <p>4:00 PM Eastern Daylight Time<br>
> 3:00 PM Central Daylight Time<br>
> 2:00 PM Moutain Daylight Time<br>
> 1:00 PM Pacific Daylight Time</p>
> </div>
>
> But I wasn't sure how the various JS-calendar-adders would handle it.

Well, here's the thing. iCalendar is weird about timezones. Instead  
of using offsets (like we do in hCalendar) or having a predefined set  
of timezones, each iCalendar stream is able to define the timezones  
it uses. Just like VEVENT, there's a thing called VTIMEZONE, which  
allows VCALENDAR stream to define precisely what it means by a  
specific timezone (offset, daylight savings time, etc).

Of course, most calendaring applications can just define this stuff  
once and ship it with the app. However, with the open web, that's not  
quite as feasible. So, since its not quite feasible to have hCalendar  
publishers define their timezones every time they publish a calendar,  
the decision was made to use datetime's with numeric offsets, which  
converting applications, a la X2V, can convert to UTC, for which we  
don't need any timezone definitions.

The root of the problem here is that AFAIK, we don't have a globally  
reference-able list of timezones*. The iCalendar RFC defers the  
problem "to future study." We probably need to do some research to  
see if anyone else has dealt with this problem since that RFC has  
been published.

> Would that be a proper implementation?

Yes, it would be. Sorry for the tangential comments.

-ryan


* FWIW, the iCalendar RFC refers to an effort to catalog timzones:  
ftp://elsie.nci.nih.gov/pub/, but I'm not sure how authoritative it is.
--
Ryan King
ryan at technorati.com