[caldeveloper-l] Recurrence override with RRULE

[Garry Shutler]

Thanks Jeffrey! I'd gone round in circles on trying to work out what the
expected behaviour was from the spec, but I'd obviously missed that part
which makes it clear.


*Garry Shutler* | CTO

On 9 April 2018 at 18:14, Jeffrey Harris <jeffrey_harris at apple.com> wrote:

> Hi Garry,
>
> From 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> 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).
>>
>> F.
>>
>>
>> ------------------------------
>> -----Original Message-----
>> From: "Garry Shutler" <garry at cronofy.com>
>> To: 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:20180323T070000zRRULE: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
>> 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/fbe03fcb/attachment.html>