Add a "between" iterator on RecurExpansion

[doganyazar]

I am trying to understand the event API. iterator() gets a start date but then uses that event as the base date-time to generate recurring events and ignores the event's original dtstart.
I am interested of finding the occurrences that happen after today for example and the only solution I found is to make a loop until it reaches the date-time I am interested in and this is not a neat solution.

  var iter = event.iterator();
   var next = iter.next();

    for (; next; next = iter.next()) {
        var occurrence = event.getOccurrenceDetails(next);
            if (isOccurrenceNow(datetime, occurence)) {
                return occurrence;
        }
    }

Am I missing something? I think from API point of view, event.iterator(startDate) would be more meaningful if it would the occurrences of the event from this point forward.

[kewisch]

I haven't looked into the RecurExpansion API in detail, @lightsofapollo might be able to help with how exactly it is intended to be used. It seems that it is acting as a wrapper that can act on multiple rrrules and friends.

I can however tell you more about the basic interfaces which may help. The recurrence APIs are leaning very much towards how its done in libical, which suggests doing exactly what you wrote: start with the "start date" of the series (hence the term), then apply the rule until you have the occurrences you are looking for. Here is an example on how its integrated into Lightning (using the lower-level interfaces): http://mxr.mozilla.org/comm-central/source/calendar/base/backend/icaljs/calRecurrenceRule.js#41

That said, I am working on a new parser that should have better performance and get you exactly what you need, the occurrences between two dates (or starting after a date, for that matter). It should be complete in a month or two, or at least be semi-usable.

In the meanwhile, I'd suggest using the approch you mentioned for now, possibly caching the occurrence dates.

[jamesdixon]

@kewisch just wanted to see if there was any update on the status of the parser you mentioned? Thanks!

[kewisch]

Yes, there is actually. Today @stephandenker and I turned in the project. There will be another commit later today that covers WEEKLY and YEARLY occurrences, but once that is done the code should pretty much work. I'll need to do some minor cleanup and commit squashing, then I can merge it in to master and create a new release. For work in progress (DAILY/MONTHLY working) see https://github.com/kewisch/ical.js/tree/recparserv2

[jamesdixon]

Fantastic! Seems that my timing was on-point for asking 👍 I just stumbled across the library and very much looking forward to using it. Thanks for your hard work!

[itung]

@kewisch I am wondering what is the api call to get all recurring occurrences between two dates. After looking at the api I can't find the api call that you state is being added to address this need. Thanks.

[mifi]

I made a wrapper for ical.js that handles this logic, however it only does so by iterating and checking:

https://github.com/mifi/ical-expander

[georgehrke]

@mifi There is place in ICAL.helpers for stuff like that. What about contributing to ical.js instead of creating a new project?

[mifi]

It started out as a module in a project I have in my company, where I needed a complete ical parser that handles all common cases like recurrence, exdate, exceptions and timezones properly. I spent a lot of time making it work properly, and I decided to pull it out as an npm module and also share it with the world, so others don't need to spend so much time on this too.

I feel that maybe ical.js is a bit lower level and not so opinionated as ical-expander, also I like to follow the UNIX style of npm modules. Keep them small and separated in concerns.

But if the authors of ical.js feel that it is a good fit in ICAL.helpers, we could try to do that. Then we could make an issue to discuss how to integrate it.

[StefanBrand]

That said, I am working on a new parser that should have better performance and get you exactly what you need, the occurrences between two dates (or starting after a date, for that matter). It should be complete in a month or two, or at least be semi-usable.

@kewisch Was this ever pulled upstream?

[castaway]

I hadn't realised this thread existed, and have written a similar thing, now wondering what the state of the mentioned one was. In mine I had to "fix" rrules that didn't specify BYDAY / BYHOUR etc to make it easier to just "generate all occurrences from now"

[StefanFabian]

Ping on the question if this was pulled upstream?

[derekantrican]

Yes, there is actually. Today @stephandenker and I turned in the project. There will be another commit later today that covers WEEKLY and YEARLY occurrences, but once that is done the code should pretty much work. I'll need to do some minor cleanup and commit squashing, then I can merge it in to master and create a new release. For work in progress (DAILY/MONTHLY working) see https://github.com/kewisch/ical.js/tree/recparserv2

@kewisch can I ask about the "v2 parser"? Looks like this branch is gone and I'm not seeing a PR for it (maybe I'm missing it). Did this get merged?

I would think it would be pretty easy write some logic to do ICAL.Event.occursOnDate(ICAL.Time) quickly & without iterating through the whole series.

[kewisch]

I did not end up pulling this work upstream. I think we did a good job putting it together at the time, though the performance gain wasn't as substantial as I had expected for the complexity it introduces. For many cases it might be straightforward, but there are certain rule parts that make it difficult.

If I were to do it again I'd optimize for certain more common use cases and fall back to the iterator if certain rule parts are included (I believe BYSETPOS was one of them). This way it can be more iterative (no pun intended).

[kewisch]

I've added some documentation on how to expand occurrences here: https://github.com/kewisch/ical.js/wiki/Common-Use-Cases. A convenience "between" iterator would make sense on RecurExpansion, especially since it can be performance optimized at any time without changing client code.