8:48 a.m.
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.