3:07 a.m.
I'm running syncevolution 1.4 on Xubuntu 14.04. My local timezone is
Pacific/Auckland. There have been no changes to Daylight Savings
start/end dates for something like seven years.
For events dated between 16 March and 5 April (final three weeks of
NZDT), if the timezone is set to Pacific/Auckland on the server, the
times on my E63 phone are one hour ahead after syncing. That is, they
are 14 hours ahead of UTC instead of 13. But if I change the timezone
for an event on the server to UTC, the correct time (13 hours ahead)
shows on the phone after syncing.
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.
I'd like to report a bug, but I have no idea which package to report it
against. Does anyone have any ideas?
Jane Atkinson
7:31 a.m.
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.
I'd like to report a bug, but I have no idea which package to
report it
against. Does anyone have any ideas?
A good start would be a syncevolution-log.html at loglevel=4 showing how
SyncEvolution transfers one event with Pacific/Auckland timezone to the
phone. That'll show how the timezones were defined in the event on the
server, internally, and in the data sent to the phone.
Doing the same on Ubuntu 12.04.4 would also be helpful as reference for
a "good" sync.
--
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.
9:47 p.m.
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.
I installed libical0 and removed libical1. A test event synced correctly.
Then replaced libical0 with libical1 and synced a second test event. The
error occurred with this one.
> I'd like to report a bug, but I have no idea which package to
report it
> against. Does anyone have any ideas?
A good start would be a syncevolution-log.html at loglevel=4 showing how
SyncEvolution transfers one event with Pacific/Auckland timezone to the
phone. That'll show how the timezones were defined in the event on the
server, internally, and in the data sent to the phone.
Doing the same on Ubuntu 12.04.4 would also be helpful as reference for
a "good" sync.
Do I still need to do this in both (X)ubuntu versions, or would it
suffice to do it with the two different libical versions (which would be
a lot simpler)?
Jane Atkinson
3:17 a.m.
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'd like to report a bug, but I have no idea which package to report it
>> against. Does anyone have any ideas?
> A good start would be a syncevolution-log.html at loglevel=4 showing how
> SyncEvolution transfers one event with Pacific/Auckland timezone to the
> phone. That'll show how the timezones were defined in the event on the
> server, internally, and in the data sent to the phone.
>
> Doing the same on Ubuntu 12.04.4 would also be helpful as reference for
> a "good" sync.
>
Do I still need to do this in both (X)ubuntu versions, or would it
suffice to do it with the two different libical versions (which would be
a lot simpler)?
Two different libical versions on the same system is good enough.
--
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.
9:04 p.m.
On 03/03/14 21:17, Patrick Ohly wrote:
On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote:
> Do I still need to do this in both (X)ubuntu versions, or would it
> suffice to do it with the two different libical versions (which would
> be a lot simpler)?
Two different libical versions on the same system is good enough.
I've run the tests. Where do I send the logs?
Jane Atkinson
2:47 a.m.
Am 04.03.2014 03:04 schrieb "Jane Atkinson" <jane(a)janeatkinson.co.nz>:
On 03/03/14 21:17, Patrick Ohly wrote:
> On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote:
>> Do I still need to do this in both (X)ubuntu versions, or would it
>> suffice to do it with the two different libical versions (which would
>> be a lot simpler)?
> Two different libical versions on the same system is good enough.
>
I've run the tests. Where do I send the logs?
Please send them to my Intel address.
10:50 a.m.
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.
I installed libical0 and removed libical1. A test event synced correctly.
Then replaced libical0 with libical1 and synced a second test event. The
error occurred with this one.
The logs that Jane sent me show a major difference between libical0 and
libical1: libical1 includes information about historic summer saving
times. This seems to break the mapping of CalDAV even timezones to
internal timezones extracted from libical such that the phone gets an
event in New_Zealand timezone (probably from libsynthesis itself) with
outdated information (?).
libical0:
TZ:+12:00
DAYLIGHT:TRUE;+13;20140927T140000Z;20150404T140000Z;NZST;NZDT
libical1:
TZ:+12:00
DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+13;20141004T140000Z;20150=
314T140000Z;New_Zealand;New_Zealand
I still need to dig deeper into this to determine why the libical
information is no longer used.
--
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.
8:29 a.m.
New subject: [SyncEvolution] Some events showing wrong time on phone - libical 1.0
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.
1:08 p.m.
New subject: [SyncEvolution] Some events showing wrong time on phone - libical 1.0
On Tue, 2014-03-11 at 13:29 +0100, Patrick Ohly wrote:
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/
As an interim solution (which, as these things tend to go, will probably
be with us for a long time) I am going to copy the relevant code libical
0.x into SyncEvolution and ensure that libsynthesis picks up that code
to populate its timezone database. That should fix the issue of syncing.
--
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.
2534
days inactive
2558
days old
syncevolution@synevolution.org
8 comments
3 participants
participants (3)
-
Jane Atkinson -
Ohly, Patrick -
Patrick Ohly