http://bugs.meego.com/show_bug.cgi?id=11233 Summary: Nokia: recurring events + alarms Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: All Architecture: --- Status: NEW Severity: normal Priority: Undecided Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: patrick.ohly(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is how a Nokia N97 sends an event which was created on the phone with: - daily recurrence until 30.12.2100 - start and end time 10:00, German time as system time - first day 12.12.2010 - reminder time 9:45, on 12.12.2010 Note that the UI implies that only one reminder will be triggered, for the first recurrence. I'm waiting for 9:45 to see whether there will be a reminder for the second recurrence... yes, there was one. BEGIN:VCALENDAR VERSION:1.0 TZ:+01 DAYLIGHT:TRUE;+02;20100328T010000Z;20101031T010000Z;; DAYLIGHT:TRUE;+02;20110327T010000Z;20111030T010000Z;; DAYLIGHT:TRUE;+02;20120325T010000Z;20121028T010000Z;; DAYLIGHT:TRUE;+02;20130331T010000Z;20131027T010000Z;; DAYLIGHT:TRUE;+02;20140330T010000Z;20141026T010000Z;; BEGIN:VEVENT SUMMARY:Phone DTSTART:20101212T090000Z DTEND:20101212T090000Z CLASS:PRIVATE RRULE:D1 #0 AALARM;TYPE=X-EPOCSOUND:20101212T084500Z;;; LAST-MODIFIED:20101213T081037Z PRIORITY:2 END:VEVENT END:VCALENDAR There is no end date set. The conversion into iCalendar 2.0 by the Synthesis engine almost correctly preserves the original semantic. It picked the Europe/Zurich time zone instead of Germany, but given no further hints by the phone, the engine cannot decide which zone was used on the phone; in practice, the two can be considered identical. BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.8//EN BEGIN:VTIMEZONE TZID:Europe/Zurich 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:20101213T081037Z CLASS:PRIVATE PRIORITY:2 SUMMARY:Phone DESCRIPTION:Phone DTSTART;TZID=Europe/Zurich:20101212T100000 RRULE:FREQ=DAILY;INTERVAL=1 DTEND;TZID=Europe/Zurich:20101212T100000 BEGIN:VALARM TRIGGER;VALUE=DATE-TIME:20101212T084500Z ACTION:DISPLAY END:VALARM END:VEVENT END:VCALENDAR Setting 31.12.2011 as specific end date instead of 30.12.2100 leads to: BEGIN:VCALENDAR VERSION:1.0 TZ:+01 DAYLIGHT:TRUE;+02;20100328T010000Z;20101031T010000Z;; DAYLIGHT:TRUE;+02;20110327T010000Z;20111030T010000Z;; BEGIN:VEVENT SUMMARY:Phone DTSTART:20101212T090000Z DTEND:20101212T090000Z CLASS:PRIVATE RRULE:D1 20111231T100000 AALARM;TYPE=X-EPOCSOUND:20101212T084500Z;;; LAST-MODIFIED:20101213T081626Z PRIORITY:2 END:VEVENT END:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.8//EN BEGIN:VTIMEZONE TZID:Europe/Zurich 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:20101213T081626Z CLASS:PRIVATE PRIORITY:2 SUMMARY:Phone DESCRIPTION:Phone DTSTART;TZID=Europe/Zurich:20101212T100000 RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20111231T100000 DTEND;TZID=Europe/Zurich:20101212T100000 BEGIN:VALARM TRIGGER;VALUE=DATE-TIME:20101212T084500Z ACTION:DISPLAY END:VALARM END:VEVENT END:VCALENDAR --------------------------- Conclusions: - a fixed, one time alarm on a Nokia phone should better be interpreted as a relative alarm, with a delta as between the first occurrence and the alarm; that's how Nokia interprets it This might be doable in conversion scripts when importing and exporting vCalendar 1.0 data. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.