problems with developing with libical

[Allen Winter]

On Saturday, October 04, 2014 03:12:42 PM Michael Cree wrote:
> I'm developing some calendar software with libical and hitting a
> number of problems that I am finding increasingly difficult to work
> around.  I had initially wrote VEVENTS with DTSTARTs, etc., without
> TZIDs which the relevant RFCes say are a floating date/time that
> float to whatever timezone one is working in.  Then I used the
> icalcomponent_foreach_recurrence() to load events within a time
> span.
> 
> But that routine:
> 
> 1) ignores the timezone of start and end arguments and interprets
> them as UTC.  The fact that the icaltimetype object carries its own
> timezone yet it appears that there are public functions implemented
> in libical which ignore the timezone carried in an icaltimetype
> object is extremely surprising (and undocumented) behaviour.
> 
> Anyway, I fix that by shifting the passed start and end argument to
> UTC before calling icalcomponent_foreach_recurrence().
> 
> 2) works solely in UTC and seems to interpret everything in UTC.
> Thus any DTSTARTs with a floating time get interpreted in UTC, not in
> the local time.  That's a huge pain to me to the point that I may
> end up having to implement icalcomponent_foreach_recurrence() in my
> own code.  I would welcome any suggestions on how to avoid that.
> 
> 3) can screw up daylight savings changes.  (I'm using libical 1.0 and
> I see that that issue may be fixed in the git repo.)
> 
> Now I am trying to write VCALENDARs with both VTIMEZONEs and VEVENTS
> and using the TZID on DTSTARTs, etc.  I am currently using the builtin
> "Pacific/Auckland" timezone and if I create a VTIMEZONE for a calendar
> by:
> 
> vtimezone = icalcomponent_new_clone(icaltimezone_get_component(tz));
> 
> where tz is the builtin icaltimezone object (I presume I should clone
> it for attaching the VTIMEZONE component to a calendar component but
> whether that is strictly necessary is not very clear from the near
> non-existant documentation) I end up getting a mile long VTIMEZONE
> component written to the calendar file, with the daylight savings time
> expanded out for each year despite the VEVENT needing only one year's
> worth of info.  (And it is wrong for most of its history as the
> builtin timezone for Pacific/Auckland is only correct for the last
> five or so years.)  Why doesn't it use a RRULE?  That's what the
> original builtin timezone in the zoneinfo directory has.  So I am
> wondering what is the best why to get a compact VTIMEZONE written
> out to an icalendar event file, and with the tzname of the VTIMEZONE
> matching the tzid value of the DTSTART parameter (as I presume they
> should)?
> 
> As a general comment, the lack of documentation, and the unexpected
> inconsistent behaviour of some of the libical interfaces means that
> one has to be very determined to persue using libical.  (And I am
> still determined at this stage but finding my enthusiasm for my
> project waning due to the amount of time wasted on working around
> instead of with libical.)
> 
Very recently I put out a general call for help to improve the documentation
but there haven't been any volunteers.  I did put up a doxygen generated
version of the apidoc at http://libical.github.io/libical/apidocs/index.html
so that might help a little.

but in general this is quite an old code base with we have only recently
been trying to modernize and improve.  we have very little time to put
into it and welcome contributions either in code or in documentation.

On the other hand, we know lots of folks are using it successfully
so we can be proud of that.