[caldeveloper-l] Recurrence override with RRULE

Jeffrey Harris jeffrey_harris at apple.com
Mon Apr 9 10:14:49 PDT 2018


Hi Garry,

From https://tools.ietf.org/html/rfc5545#page-41 <https://tools.ietf.org/html/rfc5545#page-41>

The COUNT rule part defines the number of occurrences at which to
      range-bound the recurrence.  The "DTSTART" property value always
      counts as the first occurrence.

So, for COUNT=1, you should always resolve the series to just DTSTART, and nothing more, regardless of the other details in the RRULE.

It’s weird to have RRULEs which don’t match DTSTART, but they’re legal, you just have to remember to always include DTSTART as the first occurrence.

If you set the COUNT to 2, you should get Thursday and then Tuesday.

- Jeffrey

> On Apr 9, 2018, at 8:29 AM, Garry Shutler <garry at cronofy.com> wrote:
> 
> Thanks Filip.
> 
> Rather than starting a new thread, it seems recurrence oddities come along like buses. I think in this case Calendar.app (both macOS and iOS) is expanding the series incorrectly, but as that's usually correct I thought I'd ask before submitting a bug report to them.
> 
> BEGIN:VCALENDAR
> VERSION:2.0
> CALSCALE:GREGORIAN
> BEGIN:VEVENT
> CREATED:20180401T000000Z
> DTSTAMP:20180401T000000Z
> UID:thursday-then-tuesday
> DTSTART;TZID=Europe/London:20180405T110000
> DTEND;TZID=Europe/London:20180405T120000
> RRULE:FREQ=WEEKLY;WKST=SU;COUNT=1;BYDAY=TU
> SUMMARY:Thursday then Tuesday
> SEQUENCE:0
> TRANSP:OPAQUE
> END:VEVENT
> END:VCALENDAR
> 
> When imported into Google this shows an event on 2018-04-05 (Thursday) and 2018-04-10 (following Tuesday), this seems correct to me. However, Calendar.app only shows the event on 2018-04-05 (Thursday).
> 
> From my testing the actual days of the week doesn't seem to matter but I've presented them in the form of the report we received in case it has some bearing. An event like this can be created through Calendar.app so whilst a bit of an outlier it's not an exotic hand-crafted iCalendar file or something like that.
> 
> If anyone could confirm that the Google behaviour is correct (or not!) that would be great.
> 
> Thanks,
> Garry
> 
> 
> Garry Shutler | CTO
> 
> On 5 April 2018 at 12:26, Filip Navara <navara at emclient.com <mailto:navara at emclient.com>> wrote:
> It is possible to have both properties in some cases, but it's also not universally supported and interoperable.
> 
> The case is having "RECURRENCE-ID;RANGE=THISANDFUTURE:" and then overriding the rest of a the recurring series with a new RRULE. In practice most clients split the recurrence into two separate events and deal with the consequences (https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-recursplit.txt). <https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-recursplit.txt).>
> 
> F.
>  
> 
> -----Original Message-----
> From: "Garry Shutler" <garry at cronofy.com <mailto:garry at cronofy.com>>
> To: caldeveloper-l at lists.calconnect.org <mailto:caldeveloper-l at lists.calconnect.org>
> Date: 04/05/18 12:46
> Subject: [caldeveloper-l] Recurrence override with RRULE
> 
> Hi,
> 
> We've come across a weird one which I can't decide from the RFCs how it should be dealt with (so we're going by how it's displayed when imported).
> 
> Here's a cut down example of what we've seen:
> 
> BEGIN:VCALENDAR
> VERSION:2.0
> BEGIN:VEVENT
> DTSTART:20180323T070000Z
> DTEND:20180323T083000Z
> RRULE:FREQ=DAILY
> SEQUENCE:0
> SUMMARY:example
> UID:override-with-rrule
> END:VEVENT
> BEGIN:VEVENT
> DTSTART:20180323T080000Z
> DTEND:20180323T093000Z
> RECURRENCE-ID:20180323T070000z
> RRULE:FREQ=DAILY
> SEQUENCE:0
> SUMMARY:example
> UID:override-with-rrule
> END:VEVENT
> END:VCALENDAR
> 
> I thought that a RECURRENCE-ID couldn't have a RRULE and/or that only the master should have RRULEs. I can't find anything in the RFCs to confirm this (my Google-fu/reading skills may be weak!).
> 
> To reflect what is displayed in Calendar.app we're ignoring the RRULE in the override. However, I wanted to check here to see if that's what we should be doing, whether this is valid, etc.
> 
> Cheers,
> Garry
> 
> Garry Shutler | CTO
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org <mailto:caldeveloper-l at lists.calconnect.org>
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org <http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org>
> 
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180409/853bfbb2/attachment-0001.html>


More information about the caldeveloper-l mailing list