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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
