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