On Thu, 2009-10-15 at 15:07 +0100, Stefano Maffulli wrote: 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 = 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. When I tried it, I got *1445* minutes before the event. That's correct, the absolute trigger for the alarm is one day earlier. 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. 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.

On Thu, 2009-10-15 at 17:46 +0100, Stefano Maffulli wrote: No, I'm sure the root cause is the missing support for UID and RECURRENCE-ID in the server's data model. Without that information, the GUI can't handle the two VEVENTS (or their internal representation) correctly. That would be useful. So far Funambol's position was that the server is targeting the capabilities of phones and thus doesn't have to support such advanced features. But clearly Outlook has more capabilities than a phone and is supposed to be supported. -- 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.