Subject: are blank lines allowed?

From: Damon Chaplin <[email-masked]>
Date: Mon, 25 Jun 2001 21:55:15 -0400

Quick question: are blank lines allowed in iCalendar?

I was separating VTIMEZONE components with a blank line like this for clarity:

BEGIN:STANDARD
TZOFFSETFROM:+0000
TZOFFSETTO:-000052
TZNAME:LMT
DTSTART:00010101T000000
RDATE:00010101T000000
END:STANDARD

BEGIN:STANDARD
TZOFFSETFROM:-000052
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19180101T000000
RDATE:19180101T000000
END:STANDARD

But I've been told that this isn't actually correct.

Damon

---

From: John Stracke <[email-masked]>
Date: Tue, 26 Jun 2001 10:28:22 -0400

> Quick question: are blank lines allowed in iCalendar?

[...]

> But I've been told that this isn't actually correct.

I was the one who pointed it out to Damon, when pulling in his Olson-in-iCalendar
work (for which I was very grateful, of course, and which I was able to use just
by grepping out the blank lines--no big deal).  Although RFC-2445 doesn't
actually give an overall syntax definition, I don't see any places where two
consecutive CRLFs could occur.  Each component is defined in terms of a series of
properties, and each property is defined with ABNF that includes a ":", ends in
CRLF, and does not contain any interior CRLF.

(Line folding is another issue, but it doesn't permit blank lines either, though
it would mean that a line containing a single linear-whitespace character would
be ignored.)

While I kind of like the idea of being able to insert blank lines for
readability, I think it's too late; we don't want to start sending iCalendar that
existing implementations can't accept.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"HTTP is what happens in the absence of good |
[email-masked]|design." -- Keith Moore                      |
\==============================================================/

---

From: Damon Chaplin <[email-masked]>
Date: Tue, 26 Jun 2001 23:49:36 -0400

> existing implementations can't accept.

OK. I've updated the vzic converter and VTIMEZONE files. They're at:

   http://primates.ximian.com/~damon/icalendar/

In case anyone is interested, I ran some tests against mktime. It stepped
though the years 1995-2010, every 15 minutes, converting from UTC to local
time and back again. Once using mktime/localtime, and once using the functions
I have written for libical, which use the above VTIMEZONE data.

In roughly 320 out of 350 timezones the output matched. From checking a few of
the differences I think that in a further 15-20 timezones the differences are
due to changes to the Olson database (i.e. the timezone data in my glibc is a
bit out-of-date). But I think there are probably 1 or 2 bugs still to find,
which are causing problems in the final 15-20 zones. These bugs may be in the
VTIMEZONE files, or they may be in my timezone code for libical.

Let me know if you spot any errors.

Damon