%META:TOPICINFO{author="guest" date="1048036200" format="1.0" version="1.1"}% I've just been trying to fix Timezone handling in the test files we have. Some of those are generated by Apple iCal, and do not contain vtimezones. In trying to fix this I ran into an issue with Daniel Resare's (and Java) date handling which does things relative to the timezone on the machine it is running on, which seemed to be affecting the parsing of datetimes within vtimezones which are always relative to the timezone they are describing:

"The mandatory "DTSTART" property gives the effective onset date and local time for the time zone sub-component definition. "DTSTART" in this usage MUST be specified as a local DATE-TIME value." RFC 2445, section 4.6.5.

This is a bugfix for my parser. But I'm still unclear whether in general you have to have an inline vtimezone for each vcalendar document. You can certainly point to a TZURL:

"The optional "TZURL" property is url value that points to a published VTIMEZONE definition. TZURL SHOULD refer to a resource that is accessible by anyone who might need to interpret the object. This SHOULD NOT normally be a file: URL or other URL that is not widely accessible."

- and we have these in RDF

But this, from RFC 2445, to me is ambiguous:

"An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object."

I mailed the ietf calendar list about this. They replied and said that an in-line VTimezone was required (see thread).

-- ESW.LibbyMiller - 18 Mar 2003

Last modified on 15 December 2004, at 10:31