On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote: > > On 03/03/14 01:31, Patrick Ohly wrote: > > On Sun, 2014-03-02 at 21:07 +1300, Jane Atkinson wrote: > >> I fired up my old copy of Ubuntu 12.04.4, updated it and tested to see > >> if the problem occurs there. It doesn't. > > Interesting. SyncEvolution uses system timezone data parsed by libical. > > There could be a difference between libical 1.0 (in Xubuntu 14.04) and > > older libical (Ubuntu 12.04.4) and/or in the timezone data itself. > > It looks as though libical1 may be the culprit.
The new behavior of libical1 is not really faulty. It now returns VTIMEZONE definitions which have multiple DAYLIGHT/STANDARD components instead of trying to combine those into one DAYLIGHT and STANDARD component with a suitable RRULE. The advantage is that the VTIMEZONE is now correct in all cases (the old code had issues). This was the motivation for the change, see: https://sourceforge.net/p/freeassociation/code/1130 http://sourceforge.net/p/freeassociation/bugs/76/ http://sourceforge.net/p/freeassociation/bugs/34/ The disadvantage is that not all peers and users of libical can handle this. This also caused problems in Evolution, which caused a bug report against libical asking for the old behavior to be restored: https://bugzilla.gnome.org/show_bug.cgi?id=708143 https://sourceforge.net/p/freeassociation/bugs/95/ In the case of SyncEvolution, the libical VTIMEZONEs can't be used without the RRULEs, and the fallback for New Zealand is out-dated, causing the issue currently discussed. I also expect that interoperability with peers like Google CalDAV will be affected. I am not sure what solution I can offer to SyncEvolution users. Ideally, some volunteer should implement the proposal in https://sourceforge.net/p/freeassociation/bugs/95/ -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
