problems with developing with libical

[Michael Cree]

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.)

Thanks
Michael.