Composing multiple RDATE and RRULE properties

[brianmuse]

I could be mistaken, but I believe that RFC5545 specifies that multiple RDATE properties may exist along with RRULE.

For example, this would be valid and would mean it recurs yearly and on those RDATE values:

RDATE:20160607T000000Z
RDATE:20160707T000000Z
RRULE:FREQ=YEARLY

Also, though it has SHOULD NOT guidance, you may also encounter multiple RRULE properties:

RDATE:20160607T000000Z
RDATE:20160707T000000Z
RRULE:FREQ=YEARLY
RRULE:FREQ=MONTHLY

It appears that both cannot be considered at the same time and that multiple are not supported:
https://github.com/fruux/sabre-vobject/blob/master/lib/Recur/EventIterator.php#L181-L190

        if (isset($this->masterEvent->RDATE)) {
            $this->recurIterator = new RDateIterator(
                $this->masterEvent->RDATE->getParts(),
                $this->startDate
            );
        } elseif (isset($this->masterEvent->RRULE)) {
            $this->recurIterator = new RRuleIterator(
                $this->masterEvent->RRULE->getParts(),
                $this->startDate
            );
        }

We have implemented this behavior before on another project and our technique (even supporting EXRULE) was to create an iterator for each RRULE, EXRULE and an iterator for RDATES and EXDATES and then compose result from iterating over all four of those one element at a time to get the "next" result (using logic to determine which event was actually next while handling any exceptions from EXRULE or EXDATE).

We used generators with PHP5.6, however iterators may be just as good in this case.

[evert]

Hi Brian,

I agree that this is definitely a real iCalendar feature we don't support. Most of the focus has been on trying to get support for the most common cases, and I haven't really need mixed RDATE/RRULE yet in the wild. Have you?

[brianmuse]

Thanks for the prompt reply! I can appreciate the focus on the most impactful areas.

We primarily work with the Google Calendar API where we have encountered this situation, though rare, for a few of our customers. I'm not 100% sure if they're able to someone create that state through and of the Google Calendar GUIs or whether its through another integration with Google Calendar from another schedule service or because of direct use of the Google Calendar API (which does allow this).

It's been imperative for our use case to not miss anything during instance expansion, so despite it being a bit of an edge it's still something that we have to handle.

With regards to RFC 2445 and EXRULE, though its deprecated Google Calendar actually still supports it through their API, so we try to as well.

[evert]

alright, well, I can't make any promises as to why I can get to it. There's a lot of fish to fry. So patches are definitely appreciated for stuff like that ;)

[rotdrop]

I just stumbled over this because some client submitted an event with both RRULE and RDATE, with the funny detail that the submitted RDATE was even in the past (Apple client), the relevant parts looked like this:

DTSTART;TZID=Europe/Berlin:20250703T190000
DTEND;TZID=Europe/Berlin:20250703T210000
RRULE:FREQ=WEEKLY;UNTIL=20370101T225959Z;INTERVAL=4;BYDAY=TH
RDATE=;TZID=Europe/Berlin:20250424T193000

So this was just a real-life example where some IOS app just did this.

That was with a Nextcloud instance. Maybe filing a companion bug in the NC project will help to get more fish fried earlier ;)

[rotdrop]

So if once could enhance the Eventiterator by some "union iterator then this should in principle do the trick ... something like this:

https://www.php.net/manual/en/class.appenditerator.php

Seems not too difficult ... maybe I give it a try and post a PR later on.

One problem might be that in the current state of the code the RDATE-iterator actuallly returns two items: a sibling corresponding to the DTSTART value and another sibling corresponding to the RDATE value. When combining several of such iterators the DTSTART siblings would pop up multiple times. But it should be easy to solve this by changing the RDateIterator to accept e.g. a CTOR parameter which leads to a trivial one-element iterator. Not elegant.

[rotdrop]

Argh. Reading the first comments: the iterator should present the events ascending ordered by DTSTART. Ok. So no AppendIterator, but ...

[rotdrop]

Hopefully #716 just fixes this.