timezones, question of

[Helge Hess]

On 04.02.2009, at 21:04, Till Adam wrote:
> I've come across the fact that the spec (2.0rc7) specifies that all  
> times shall be UTC, without timezone information. Now, this is  
> clearly a simple and interoperable choice, and it works fine, so  
> far. It does lead to a bit of lost information, in some use cases,  
> though, some of which happen to be used by me, which got me thinking.

As a matter of fact preserving timezone information is a necessity for  
recurring events. You can't properly express calculated recurrences  
spanning DST changes w/o it.


> RFC 2445 uses TZID, referencing the Olson timezone database


Thats incorrect. A TZID always references a VTIMEZONE embedded in the  
iCalendar entity. It has nothing to do with Olson (Olson is just  
mentioned as one example which an implementor could use).

> ICAL solves this by allowing any timezone id to be used and the  
> description of that timezone to be shipped along with the even as a  
> VTIMEZONE component.

Nitpicking, but iCal _requires_ that the timezone is shipped with the  
entity. And the client must parse that timezone and use it.

Since VTIMEZONE objects can use arbitrary RRULEs to define the  
timezone, its quite a complex topic. Most interesting is what to do if  
the client can't express the timezone. (eg Outlook).


> So I see three options, which I'd like your feedback on, dear  
> interested public:
> 1) leave things as is, and don't bother
> 2) implement the ical approach of a timezone description that is  
> shipped along
> 3) come up with a standard timezone id format and map to local/ 
> native representations on the client

BTW: as we speak there is a CalConnect event with a focus on timezones:

   http://www.calconnect.org/calconnect14.shtml

Would be interesting to see what they come up with ... AFAIK an  
official timezone registry is in discussion.

Greets,
   Helge