Zend\Ical – A long term journey

Wednesday, August 31, 2011

About four years ago, I proposed Zend_Ical to the public, a component, which should enable everyone to read, create, and work with iCalender files. At that point, I had no idea about how complex the entire topic is. I were interrupted multiple times by other components with a higher priority, so I only worked on it from time to time. I where asked a lot about when the component would be done, and my usual answer was "I am working on it". Surely, most of the time, that was a lie.

Since creating the proposal, I refactored the Zend\Ical component about five times, especially the parser itself. About two weeks ago I started working on it again. I don't exactly know why, I somehow felt motivated. So I started finishing the parser and creating a complete new data structure whithin just two days with the help of libical, the official reference implementation. I occasionally noticed that I was working against the old RFC 2445, which was superseded by RFC 5545 in 2009. Fortunately it only added a few minor restrictions, but also a lot of clarifications of yet vague topics. After upgrading Zend\Ical to reflect the new RFC, I had to notice that there was a second, and also very important, RFC 5546, which adds further restrictions based on the calendar's METHOD property. This resulted in the data structure and parser being completly useless, so I had to make a final rewrite of it.

A week ago, I was able to finish the parser to a certain amount, enough to start testing the different value types. I adopted the recurrence iterator from libical, but fixed a few bugs and added missing restrictions. It is not complete by now, but it contains enough logic to work with most timezone definitions. After that, I searched for a way to create timezone components from timezone identifiers. The solution was the Olson TZ database together with vzic, which converts the Olson timezones to iCalendar timezones.

Right now I'm working on the timezone functionality, to be able to convert local dates to UTC timestamps and vice versa. If you are interested in the current code, you can take a look at it in my GitHub repository.

Comments to this article

  • Avatar of lcf_ Reply lcf_ Wednesday, August 31, 2011 6:30 PM

    good news! Four years, huh...

    Just one thing I didn't get clearly so would appreciate a comment from you:

    >> After that, I searched for a way to create timezone components from timezone identifiers. The solution was the Olson TZ database together with vzic, which converts the Olson timezones to iCalendar timezones.

    What is "iCalendar timezones" refers to exactly? Is there a full list, a standard? Would this statement mean that at some point a "TZID" element would be relied upon rather than on the timezone definition in the .ics itself?

    • Avatar of Ben Scholzen 'DASPRiD' Reply Ben Scholzen 'DASPRiD' Wednesday, August 31, 2011 6:34 PM

      By iCalendar timezones I meant VTIMEZONE definitions of all common timezones. This means that when someone injects a \DateTime object, Zend\Ical can look up it's timezone-identifier, and generate the regarding VTIMEZONE component for it.

      • Avatar of lcf_ Reply lcf_ Wednesday, August 31, 2011 6:39 PM

        But it can be anything, can't it? TZID is only to refer to a Timezone from WITHIN a calendar. To generate a VTIMEZONE component you just need the rules for it i.e. Daylight/Standard offsets.

        I'm not an expert here neither I'm arguing, just curious.

        • Avatar of Ben Scholzen 'DASPRiD' Reply Ben Scholzen 'DASPRiD' Wednesday, August 31, 2011 6:42 PM

          Sure, this ist just helepr functionallity, so you as developer do not have to worry about timezone definitions, even tho you can create any timezone, if you want.

          • Avatar of lcf_ Reply lcf_ Wednesday, August 31, 2011 6:51 PM

            Why to convert a timezone from one format to another? What does it change? You can use any TZID you want (am I right here?) so why not just use the one you already have in the Zend_Date object and not to convert it to smth else.

            It's not a hard task to do, but is there a reason why to do this complexity?

            Also, just to make sure: when parsing a .ics file, a timezone with a custom and unknown TZID which can't be found in any database - would it work as expected? (this really happens sometimes - one of the reasons I've been following your updates on Zend\Ical all these years :))

            • Avatar of Ben Scholzen 'DASPRiD' Reply Ben Scholzen 'DASPRiD' Wednesday, August 31, 2011 6:54 PM

              Yes, any VTIMEZONE component will work (event with non-common timezone identifiers), that's the idea behind Zend\Ical. And that's again the reason for converting the Olson timezone files to VTIMEZONE: Zend\Ical needs the VTIMEZONE components for working with the iCalender DateTime objects.

  • Avatar of Edward Savage Reply Edward Savage Thursday, September 1, 2011 3:10 PM

    This is awesome Ben! I can't wait to dig into your code.

Leave a comment

Please note that your email address will not be shown, it is only used to fetch your avatar image from gravatar.com and for notifications. 

             _     _            
 _ __   ___ | |__ (_) __ _  ___ 
| '_ \ / _ \| '_ \| |/ _` |/ _ \
| | | | (_) | |_) | | (_| |  __/
|_| |_|\___/|_.__/|_|\__, |\___|
                     |___/