http://bugs.meego.com/show_bug.cgi?id=11241
Summary: Nokia: recurring events: recurrence rule not
understood by phone
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
CC: [email protected], [email protected],
[email protected]
Depends on: 11233
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.
--- Comment #1 from pohly <[email protected]> 2010-12-13 02:03:21 PST ---
+++ This bug was initially created as a clone of Bug #11233 +++
This was sent to us by the phone:
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
Translated into:
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
After changing the summary, it is sent back to the phone as an update as:
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01:00
DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+02;20110327T010000Z;20111=
030T010000Z;CET;CEST
BEGIN:VEVENT
LAST-MODIFIED:20101213T091201Z
CLASS:PRIVATE
PRIORITY:2
SUMMARY:Phone mod
DESCRIPTION:Phone
DTSTART:20101212T090000Z
RRULE:D1 20111231
DTEND:20101212T090000Z
AALARM:20101212T084500Z;;;Phone mod
DALARM:20101212T084500Z;;;Phone mod
END:VEVENT
END:VCALENDAR
The phone now ignores the recurrence.
Disabling the alarm:
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01:00
DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+02;20110327T010000Z;20111=
030T010000Z;CET;CEST
BEGIN:VEVENT
LAST-MODIFIED:20101213T091741Z
CLASS:PRIVATE
PRIORITY:2
SUMMARY:Phone mod
DESCRIPTION:Phone
DTSTART:20101212T090000Z
RRULE:D1 20111231
DTEND:20101212T090000Z
END:VEVENT
END:VCALENDAR
Still no recurrence on the phone. Switching to UTC also doesn't help.
One relevant difference might be the explicit time in the RRULE. The phone
includes it, the Synthesis engine doesn't. Yep, that seems to be it. Both
"forever" (RRULE:D1 #0) and "fixed number of times" work.
The later one is interesting, because the Synthesis engine internally converts
it into a fixed end date:
RRULE;X-EVOLUTION-ENDDATE=20101219T100000Z:FREQ=DAILY;COUNT=7
# [2010-12-13 10:34:44.466] - calculating end date now
# [2010-12-13 10:34:44.466] endDateFromCount: daily calc - same in all cases
# [2010-12-13 10:34:44.466] - leaving with freq D, freqmod , interval 1,
firstmask 0, lastmask 0
# [2010-12-13 10:34:44.466] RRULE2toInternal(): extracted until
'20101218T100000Z'
- 13 : string RR_FREQ [ 0, -1, 2] : "D "
- 14 : integer RR_INTERVAL [ 0, 0, 0] : 1
- 15 : integer RR_FMASK [ 0, 0, 0] : 0
- 16 : integer RR_LMASK [ 0, 0, 0] : 0
- 17 : timestamp RR_END [ 0, 0, 0] : 2010-12-18T10:00:00Z
(TZ: UTC)
BEGIN:VCALENDAR
VERSION:1.0
TZ:+00:00
DAYLIGHT:FALSE
BEGIN:VEVENT
LAST-MODIFIED:20101213T093438Z
CLASS:PRIVATE
PRIORITY:2
SUMMARY:Phone mod
DESCRIPTION:Phone
DTSTART:20101212T100000Z
RRULE:D1 20101218T100000Z
DTEND:20101212T100000Z
END:VEVENT
END:VCALENDAR
This is displayed fine on the phone, confirming that 20101218T100000Z is needed
in RRULE.
In comparison, here's the full conversion for "recurs until":
RRULE:FREQ=DAILY;UNTIL=20101231
# [2010-12-13 10:51:06.983] - extracted until 20101231T000000Z
# [2010-12-13 10:51:06.983] - leaving with freq D, freqmod , interval 1,
firstmask 0, lastmask 0
# [2010-12-13 10:51:06.983] RRULE2toInternal(): extracted until '20101231'
- 17 : timestamp RR_END [ 0, 0, 0] : 2010-12-31 (floating)
- 18 : timestamp DTSTART [ 0, -1, 0] : 2010-12-12T10:00:00Z
(TZ: UTC)
- 19 : timestamp DTEND [ 0, -1, 0] : 2010-12-12T10:00:00Z
(TZ: UTC)
RRULE:D1 20101231
The spec says that the end date must contain a time:
enddate::= ISO 8601_date_time value(e.g., 19940712T101530Z)
It does not say whether that end datetime is included in the recurrence, but
experiments show that this is the interpretation on the phone (vCalendar 1.0)
and in Evolution (iCalendar 2.0).
Given that vCalendar does not allow floating end dates, I think the encoder for
vCalendar RRULE should be fixed to not generate such broken rules. What time it
should insert as fallback might be a bit tricky, but I think the start time of
the event should do.
--
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.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues
