[Syncevolution-issues] [MeeGo Projects - Bug 11241] New: Nokia: recurring events: recurrence rule not understood by phone

Monday, 13 December 2010

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: syncevolution-bugs(a)meego.bugs
        ReportedBy: patrick.ohly(a)intel.com
         QAContact: jingke.zhang(a)intel.com
                CC: patrick.ohly(a)intel.com, syncevolution-bugs(a)meego.bugs,
                    syncevolution-default-bugs(a)meego.bugs
        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 <patrick.ohly(a)intel.com&gt; 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.

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

[Syncevolution-issues] [MeeGo Projects - Bug 11241] New: Nokia: recurring events: recurrence rule not understood by phone