[uf-discuss] hCalendar Implementation

Fri Jan 13 12:49:37 PST 2006

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月23日T16: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