[SyncEvolution] Some events showing wrong time on phone - libical 1.0

[Patrick Ohly]

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.