3:13 a.m.
On Thu, 2009-10-15 at 15:07 +0100, Stefano Maffulli wrote:
Hello folks,
I've stumbled upon a small issue that I hope you'll help me figure out.
I'm using Evolution 2.26.1 shipped in Ubuntu Jaunty 9.04 and latest
syncevolution stable from the syncevolution deb repository.
On the myFUNAMBOL portal I create a recurring event with a reminder 5
minutes before the start. I then sync to Evolution with latest stable
SyncEvolution. The event syncs correctly, the recurrence is maintained
intact but the reminder is displaced to 30 minutes.
I reproduced this by creating a recurring event from 18:00-19:00. I got
this from the server:
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT
BEGIN:STANDARD
DTSTART:19700101T000000
RDATE:19700101T000000
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
TZNAME:GMT
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Recurring
CLASS:PUBLIC
DTSTART;TZID=GMT:20091015T180000
DTEND;TZID=GMT:20091015T190000
RRULE;TZID=GMT:FREQ=DAILY;INTERVAL=1;UNTIL=20091022T180000
X-FUNAMBOL-ALLDAY:0
BEGIN:VALARM
TRIGGER;TZID=GMT;VALUE=DATE-TIME:20091015T175500
REPEAT:0
END:VALARM
END:VEVENT
END:VCALENDAR
I checked the myFUNAMBOL settings. It thinks that I am in Africa/Abidjan
(GMT +00:00), so sending the event with 18:00-19:00 UTC is correct.
However, the TRIGGER;TZID=GMT;VALUE=DATE-TIME:20091015T175500 looks
wrong to me.
First, it is in local time (no TZID, not UTC). That means that with me
being in Germany (currently at GMT +02:00), the alarm should go off at
17:55 local time, 2:05 hours before the meeting at 20:00 local time.
However, Evolution correctly displays the alarm time as "19:55". It
seems to use the "timezone" of the DTSTART/END also for the DATE-TIME of
the alarm, which IMHO is wrong.
Second, the alarm triggers only once, on 2009-10-15. This seems
inconsistent with the web interface, where I selected "5 minutes",
meaning 5 minutes before each recurrence. The server should have sent
TRIGGER:-PT05M.
I'm not sure where your 30 minute displacement came from. You would have
to check your log files and look at the specific event plus your time
zone settings to determine that. If you run with loglevel =
I modify one occurrence of the recurring event on Evolution,
modifying
the notes for example. I sync again. On the myFUNAMBOL portal at this
point I see the original series of recurring event *and* a new event
that is similar in subject and time to the series but has the modified
notes.
myFUNAMBOL doesn't support "detached recurrences", as far as I know.
What you have sent to the server is a VEVENT with the same UID as the
recurring event plus a RECURRENCE-ID for the day that you modified. In
iCalendar 2.0 that means that the new VEVENT "overrides" the regular
recurrence. The server therefore shouldn't display the regular
recurrence. I'm sure your colleagues are aware of this, we've already
discussed it on the Funambol mailing lists a while ago.
The new event has also a modified reminder: 115 minutes instead
of 5. The other event, the recurring one, has kept the 5 minutes
reminder.
When I tried it, I got *1445* minutes before the event. That's correct,
the absolute trigger for the alarm is one day earlier.
If I sync again the new 'cloned event' is *not* transfered to
the
Evolution calendar. The Evolution calendar keeps the information intact:
one event, recurring, reminder 30 minutes.
Client and server are in sync, they just interpret the same data
differently. Evolution knows about detached recurrences and thus only
displays the event once on the day where it was modified. Force a
refresh from server and Evolution will display two events, because the
UID (which is critical for detached recurrences) gets lost on the
server.
Can you explain why this is happening? Where is the bug?
myFUNAMBOL?
I wonder how the Funambol Outlook client deals with these problems.
Outlook supports detached recurrences.
--
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.