#95 Regression: VTIMEZONE contains a lot of non-used timezone info, what mess with Google Calendar, EWS Calendar, etc ...

[Fabiano Fidêncio]

I've bisect the code and I found the regression was inserted in svn://svn.code.sf.net/p/freeassociation/code/trunk/libical@1130

For a clearer understanding of the problem, you also can find two calendars attached. The "expected_calendar.ics", was generated using latest libical with r1130 reverted; you can see it is populating VTIMEZONE only with used timezones. The "wrong_calendar.ics", on the other hand, is populating VTIMEZONE with a lot of non-used timezones.

Also, you can find the patch reverting the r1130.

Please, let me know what kind of info I can provide to you to fix it.

Ah, moreover, two related bugs0 were filled against Evolution (and its componentes), both can be fixed reverting r1130.

[Patrick Ohly]

This change of behavior in libical is also causing regressions in SyncEvolution (http://comments.gmane.org/gmane.comp.mobile.syncevolution/4757). SyncEvolution needs to exchange data with peers which cannot handle VTIMEZONEs with multiple STANDARD and DAYLIGHT components or cannot receive them in the first place (phones still based on vCalendar 1.0).

It's debatable whether this is a regression in libical. The reason for the change (getting rid of code which did not work in all cases) is valid, although perhaps it would have been useful to ask libical consumers first.

I think the right solution is to introduce a new method in libical that creates a VTIMEZONE for a specific event and/or time range. Then apps which need to export the event can produce a suitable VTIMEZONE that peers can handle.

[Allen Winter]

Fixed in the upcoming 2.0 release.

By default nothing has changed, but now you have a buildtime and a runtime ability
to switch the behavior from exact to inter-operable VTIMEZONEs.

First the buildtime switch. if you want to build libical to use inter-operable VTIMEZONEs
without changing your code, then pass the option -DUSE_INTEROPERABLE_VTIMEZONES=true to cmake.

If you are are forced to use a libical that was built without inter-operable VTIMEZONEs as the default,
then you'll need to call icaltzutil_set_exact_vtimezones_support(1) from your application at runtime.

You can also query the VTIMEZONE "mode" by calling the icaltzutil_get_exact_vtimezones_support() function.

I hope this covers every scenario and now consider this issue closed (well, except for possible silly coding errors I may have made)