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


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.

3 Attachments


  • Patrick Ohly
    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.