9:13 a.m.
Hello, and happy 2015 year to all list members.
Linux Mint Debian, Evolution 3.8.5, SyncEvolution 1.5.
I have noticed that when I sync from Evolution to my phone (Nokia E72),
the calendar item is 1 hour late on the Nokia. But when I sync from the
phone to Evolution, there is no such offset.
I'm puzzled, AFAICT it was not the case before we switched to winter
time. On the phone, as usual, it was automatic, and then I got the
message that "calendar entries had been updated". But I had never seen
this offset the years before.
Evolution is set to "use system time zone", and the phone gets its time
from the GSM network.
TIA for any input about this. Best regards,
--
Daniel CLEMENT
9:05 a.m.
Hmm. More and more obscure after looking directly at the OneMediaHub
(formerly Funambol) calendar with their Web interface (which is set up
to the same time zone):
Nokia E72 <==> OneMediaHub: OK (both ways)
OneMediaHub ==> Evolution: OK
Evolution ==> OneMediaHub: +1 hour on the OneMediaHub calendar :-(
Le samedi 03 janvier 2015 à 18:13 +0100, Daniel CLEMENT a écrit :
Hello, and happy 2015 year to all list members.
Linux Mint Debian, Evolution 3.8.5, SyncEvolution 1.5.
I have noticed that when I sync from Evolution to my phone (Nokia E72),
the calendar item is 1 hour late on the Nokia. But when I sync from the
phone to Evolution, there is no such offset.
I'm puzzled, AFAICT it was not the case before we switched to winter
time. On the phone, as usual, it was automatic, and then I got the
message that "calendar entries had been updated". But I had never seen
this offset the years before.
Evolution is set to "use system time zone", and the phone gets its time
from the GSM network.
TIA for any input about this. Best regards,
--
Daniel CLEMENT
5:47 a.m.
On Sat, 2015-01-03 at 18:13 +0100, Daniel CLEMENT wrote:
Hello, and happy 2015 year to all list members.
Linux Mint Debian, Evolution 3.8.5, SyncEvolution 1.5.
I have noticed that when I sync from Evolution to my phone (Nokia E72),
the calendar item is 1 hour late on the Nokia. But when I sync from the
phone to Evolution, there is no such offset.
I'm puzzled, AFAICT it was not the case before we switched to winter
time. On the phone, as usual, it was automatic, and then I got the
message that "calendar entries had been updated". But I had never seen
this offset the years before.
Evolution is set to "use system time zone", and the phone gets its time
from the GSM network.
TIA for any input about this. Best regards,
Such cases are always hard to diagnose without examples.
It would help to compare the data sent by the phone and data sent by
SyncEvolution. Use loglevel=4 and then check syncevolution-log.html for
"parsing" and "generated" dumps of the event in question.
--
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:42 a.m.
Hello, sorry for the delay in the reply, I was away this week.
Le lundi 09 février 2015 à 14:47 +0100, Patrick Ohly a écrit :
On Sat, 2015-01-03 at 18:13 +0100, Daniel CLEMENT wrote:
> Hello, and happy 2015 year to all list members.
>
> Linux Mint Debian, Evolution 3.8.5, SyncEvolution 1.5.
>
> I have noticed that when I sync from Evolution to my phone (Nokia E72),
> the calendar item is 1 hour late on the Nokia. But when I sync from the
> phone to Evolution, there is no such offset.
>
> I'm puzzled, AFAICT it was not the case before we switched to winter
> time. On the phone, as usual, it was automatic, and then I got the
> message that "calendar entries had been updated". But I had never seen
> this offset the years before.
>
> Evolution is set to "use system time zone", and the phone gets its time
> from the GSM network.
>
> TIA for any input about this. Best regards,
Such cases are always hard to diagnose without examples.
It would help to compare the data sent by the phone and data sent by
SyncEvolution. Use loglevel=4 and then check syncevolution-log.html for
"parsing" and "generated" dumps of the event in question.
I observe this offset with every event created in Evolution. As I said
in another message, I was could check that phone <==> Funambol server
was OK both ways (which is expected, since the phone uses the Funambol
client, not Syncevolution). The only problem is Evolution ==> Funambol
server.
So I created a dummy event "Livraison" (delivery) scheduled next Tuesday
(0217), 14.00 to 14.30 (Paris time).
Below is the contents of syncevolution-log.html for this event under
"generated" (no "parsing", which I assume normal as the event is
new).
The event ends up on the Funambol (OneMediaHub) server 1 hour late
(15.00).
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:STANDARD
DTSTART:19671029T030000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870329T020000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20150215T154110Z
DTSTAMP:20150215T154605Z
CREATED:20150215T154110Z
UID:20150215T154058Z-5357-1000-3781-0@m6400
SEQUENCE:2
CLASS:PUBLIC
TRANSP:OPAQUE
SUMMARY:Livraison
DESCRIPTION:Livraison
DTSTART;TZID="Europe/Paris":20150217T140000
DTEND;TZID="Europe/Paris":20150217T143000
END:VEVENT
END:VCALENDAR
So I corrected the time directly on the OneMediaHub Web site and re-run
the sync. Here is the new contents (under "parsing" this time):
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:DAYLIGHT
DTSTART:20140330T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:Europe/Paris
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20141026T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:Europe/Paris
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:20150215T154058Z-5357-1000-3781-0@m6400
SUMMARY:Livraison
DESCRIPTION:Livraison
CLASS:PUBLIC
DTSTART;TZID=Europe/Paris:20150217T140000
DTEND;TZID=Europe/Paris:20150217T143000
X-FUNAMBOL-ALLDAY:0
END:VEVENT
END:VCALENDAR
I see strange things in the TZ name (CET vs. CEST vs. Europe/Paris, with
or without quotes)... Could that be the problem?
Best regards,
--
Daniel CLEMENT
1:52 a.m.
On Sun, 2015-02-15 at 17:42 +0100, Daniel CLEMENT wrote:
Hello, sorry for the delay in the reply, I was away this week.
Le lundi 09 février 2015 à 14:47 +0100, Patrick Ohly a écrit :
> On Sat, 2015-01-03 at 18:13 +0100, Daniel CLEMENT wrote:
> > Hello, and happy 2015 year to all list members.
> >
> > Linux Mint Debian, Evolution 3.8.5, SyncEvolution 1.5.
> >
> > I have noticed that when I sync from Evolution to my phone (Nokia E72),
> > the calendar item is 1 hour late on the Nokia. But when I sync from the
> > phone to Evolution, there is no such offset.
> >
> > I'm puzzled, AFAICT it was not the case before we switched to winter
> > time. On the phone, as usual, it was automatic, and then I got the
> > message that "calendar entries had been updated". But I had never
seen
> > this offset the years before.
> >
> > Evolution is set to "use system time zone", and the phone gets its
time
> > from the GSM network.
> >
> > TIA for any input about this. Best regards,
>
> Such cases are always hard to diagnose without examples.
>
> It would help to compare the data sent by the phone and data sent by
> SyncEvolution. Use loglevel=4 and then check syncevolution-log.html for
> "parsing" and "generated" dumps of the event in question.
>
I observe this offset with every event created in Evolution. As I said
in another message, I was could check that phone <==> Funambol server
was OK both ways (which is expected, since the phone uses the Funambol
client, not Syncevolution). The only problem is Evolution ==> Funambol
server.
So I created a dummy event "Livraison" (delivery) scheduled next Tuesday
(0217), 14.00 to 14.30 (Paris time).
Below is the contents of syncevolution-log.html for this event under
"generated" (no "parsing", which I assume normal as the event is
new).
The event ends up on the Funambol (OneMediaHub) server 1 hour late
(15.00).
[...]
DTSTART;TZID="Europe/Paris":20150217T140000
[...]
I see strange things in the TZ name (CET vs. CEST vs. Europe/Paris,
with
or without quotes)... Could that be the problem?
The quotation marks around the TZID parameter value seem to be the
problem. I removed them and then it works. It seems that the Funambol
iCalendar 2.0 parser fails to remove the marks and then does not apply
the correct time zone when storing the event.
This is a bug in Funambol, there's nothing wrong with using redundant
(in this case) quotation marks. Can you report this problem to Funambol
and report back what the response is and/or provide a link to the bug
report?
SyncEvolution started using these quotation marks in 1.4.99.2 when
fixing incorrect escaping via backslash. It is not required to quote the
Europe/Paris value; SyncEvolution does it because it has a fairly
conservative list of characters that are allowed without quoting. I can
add the slash to that white list and include that change in 1.5.1, but I
don't know when I'll release that.
If you want to compile from source, then patch like this:
diff --git a/src/sysync/mimedirprofile.cpp
b/src/sysync/mimedirprofile.cpp
index e618f80..384e7dc 100644
--- a/src/sysync/mimedirprofile.cpp
+++ b/src/sysync/mimedirprofile.cpp
@@ -2378,6 +2378,7 @@ sInt16 TMimeDirProfileHandler::generateValue(
if (aParamValue) {
for (const char *p=val.c_str();(c=*p)!=0;p++) {
if (!(isalnum(c) ||
+ c == '/' ||
c == '-' ||
c == '_')) {
quotedstring = true;
--
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.
3:07 a.m.
Le lundi 16 février 2015 à 10:52 +0100, Patrick Ohly a écrit :
[...]
> DTSTART;TZID="Europe/Paris":20150217T140000
[...]
The quotation marks around the TZID parameter value seem to be the
problem. I removed them and then it works.
I never would have thought that!
It seems that the Funambol
iCalendar 2.0 parser fails to remove the marks and then does not apply
the correct time zone when storing the event.
This is a bug in Funambol, there's nothing wrong with using redundant
(in this case) quotation marks. Can you report this problem to Funambol
and report back what the response is and/or provide a link to the bug
report?
I did my best, but they only have a support forum. I posted there
http://help.onemediahub.com/?topic=bug-in-funambol-parser
you're welcome to add to my own post if you think it's unclear.
SyncEvolution started using these quotation marks in 1.4.99.2 when
fixing incorrect escaping via backslash.
Hmm... I'm pretty certain my syncing has worked since then (even with
version 1.5). So, something must have changed on the Funambol side.
It is not required to quote the
Europe/Paris value; SyncEvolution does it because it has a fairly
conservative list of characters that are allowed without quoting. I can
add the slash to that white list and include that change in 1.5.1, but I
don't know when I'll release that.
If you want to compile from source, then patch like this:
[...]
I'll try the patch ASAP, but not sure when.
Best regards,
--
Daniel CLEMENT
2731
days inactive
2775
days old
syncevolution@synevolution.org
5 comments
2 participants
participants (2)
-
Daniel CLEMENT -
Patrick Ohly