Is there a change that this PR will be merged?

Hey! As already said in a few places (see here or here), I'm currently working on the next version of ics.py and RRULEs are something I'd love to finally have proper support for. So, first of all, a big thank you for your contribution! Especially interpreting the rule and generating the next occurrences was probably a lot of work. The only thing I'm wondering about is whether we could build upon the rrule functionality of dateutil (which is already a dependency of ics.py) to reduce complexity a little on our side. I didn't read into the details of RRULEs yet, so it would be great to hear your opinion in this case!

Hey. Thank you! The rrule functionality of dateutil has already all the functions needed. I can't imagine a scenario where you will need more than what it is already implemented, but nonetheless if you need to implement helper functions it wouldn't be too much work. I encourage the use of dateutil for rrules.

I could use rrule support, is there any chance this PR could be merged soon?

Looks like this will also need to be updated to replace arrow with the native datetime as arrow has been removed in #222

Hey, PR #249 adds rrule support based on the dateutil library using the new serialization infrastructure, superseding this PR. The initial goal was to enable correct handling of vTimezones (see e.g. here for a working example), but that should also be directly transferable to Events. This PR is still open because I still need to cherry-pick the recurrence handling for the query operations of Event and Timeline into the other PR.

PR #249 still needs some polish, but we should be able to merge that soonish. After that, the only thing that is in the way of a v0.8 alpha release is probably some possibility to tune down the parser strictness, as the new parser implementation (which was focussed on also being able to validate files) sometimes seems to nit-picky to handle practically real-world data with it.

Anything we can do to help to add rrule support? I'd very much appreciate this

Support for parsing rrules is already merged, so you could try adding an rruleset field to the CalendarEntryAttrs class (so that both Event and ToDo get that functionality). The harder part is then correctly interpreting repetitions, especially when instantiating a repeating event or when parsing a recurring event with modifications to individual instances, see this or this article for an introduction on this complexity. Fortunately, there is at least some prior work, but we probably should also check how the big Calendaring solutions (Google, Apple, Thunderbird, Evolution and probably breaking everything, Outlook) do this. The big issue then is to design a user-facing API that helps with

• creating modified instances of repeating events, also including cancellations
• linking a modified instance back to its original instance, where the modication was possibly done by some other software
• listing all the actual occurences of a recurring event, taking modified instances and cancellations into account
  (here we also need to think about how to represent recurrence instances that haven't been modified, i.e. won't become separate objects in the ics file)

As far as I'm aware, this PR only tackled the last point while ignoring modified instances. So copying the respective changes over might be helpful, but there still is a lot of work to do here, but maybe we can reuse parts of the recurring-ical-events project (depending on the extent of this, we might need to be aware that this pulls in LGPLv3 code, but that should be fixable), and their testsuite should also be very useful. So maybe try looking at what RFC 5545 officially mandates, how recurring-ical-events solved that and what other Calendaring solutions do, and try to come up with an API that tackles the 3 points listed above.

I'm doing a bit of cleanup. This PR seems stale and not ready to be merged so i'll close it but if somebody wants to work on it again, feel free to reopen !