Thanks for your report, but this is a duplicate of #230. Please follow up there.
RDATE: missing first instance and time zone ignored
-
- rfc2822 notifications@github.com [2014-11-12 06:21]:
So it seems that the RDate string can’t be passed 1:1 into the database as the docs say. Do you agree?
Yes, I guess you have to replace ‘:’ by ‘;’.
I have confirmed that for the given VEVENT, the start event doesn’t appear in the calendar as soon as RDATE is set. However, DAVdroid clearly adds the event to the database (as it’s only one row and the recurrence dates appear in the calendar). The only difference is that in the latter case, it sets DURATION=PT0S instead of a DTEND as required by the docs.
What about adding DTSTART to the RDATE set?
-
Yes, I guess you have to replace ‘:’ by ‘;’.
Hm, I guess Android people would replace “;” by “:” instead? Or at least change the docs. If this can be confirmed, I’d even provide a patch for AOSP.
What about adding DTSTART to the RDATE set?
I’d do that if that requirement was documented in the Android docs. I’d prefer to locate the actual problem (and why it doesn’t occur with RRULE) and provide a fix for AOSP.
-
Adding a patch to AOSP sounds good as well, the other ideas could be
helpful to be backward compatible. -
- Regarding the time zones: DAVdroid now writes the TZID (if set) to the Calendar provider, causing the recurring instances to have correct time. The time zone are not shown in the calendar due Android recurrence processing, but the time should be correct.
- Regarding the missing first instance: Android’s RecurrenceProcessor method expand() is responsible for expanding the recurrence. It’s called with both DTSTART and RDATE, but it only returns the RDATE recurrences. CalendarInstancesHelper takes
- DTSTART in case of non-recurring events,
- the result of
RecurrenceProcessor.expand(DTSTART,RDATE)
(which does not include the DTSTART instance) in case of recurring events
as the instance date(s), so it misses the DTSTART instance in case of recurring events.
So I consider this an Android bug; I guess it’s caused by a non-precise specification of whether``RecurrenceProcessor.expand(DTSTART,RDATE)
shall return the first instance or not. Because of this missing specification, wrong assumptions are made in
CalendarInstancesHelper`, causing this bug. -
Please also follow up at https://code.google.com/p/android/issues/detail?id=171292
-
As the time zone issue has been fixed in DAVdroid, I’ll consider this issue as a third-party bug from now on.
-
Hi rfc2822, thanks for taking care of this!
-
Let’s see whether this issue will be fixed in Android.
-
For reference, I’ve worked around these two here: https://github.com/jspricke/python-remind/blob/master/remind.py#L165
-
Please see also https://code.google.com/p/android/issues/detail?id=172442