What's the best way to model recurring events in a calendar application?

Question

I\'m building a group calendar application that needs to support recurring events, but all the solutions I\'ve come up with to handle these events seem like a hack. I can li

Answer 1

From these answers, I've sort of sifted out a solution. I really like the idea of the link concept. Recurring events could be a linked list, with the tail knowing its recurrence rule. Changing one event would then be easy, because the links stay in place, and deleting an event is easy as well - you just unlink an event, delete it, and re-link the event before and after it. You still have to query recurring events every time someone looks at a new time period never been looked at before on the calendar, but otherwise this is pretty clean.

Answer 2

Martin Fowler - Recurring Events for Calendars contains some interesting insights and patterns.

Runt gem implements this pattern.

Answer 3

For .NET programmers who are prepared to pay some licensing fees, you might find Aspose.Network useful... it includes an iCalendar compatible library for recurring appointments.

Answer 4

I have developed multiple calendar-based applications, and also authored a set of reusable JavaScript calendar components that support recurrence. I wrote up an overview of how to design for recurrence that might be helpful to someone. While there are a few bits that are specific to the library I wrote, the vast majority of the advice offered is general to any calendar implementation.

Some of the key points:

• Store recurrence using the iCal RRULE format -- that's one wheel you really don't want to reinvent
• Do NOT store individual recurring event instances as rows in your database! Always store a recurrence pattern.
• There are many ways to design your event/exception schema, but a basic starting point example is provided
• All date/time values should be stored in UTC and converted to local for display
• The end date stored for a recurring event should always be the end date of the recurrence range (or your platform's "max date" if recurring "forever") and the event duration should be stored separately. This is to ensure a sane way of querying for events later.
• Some discussion around generating event instances and recurrence editing strategies is included

It's a really complicated topic with many, many valid approaches to implementing it. I will say that I've actually implemented recurrence several times successfully, and I would be wary of taking advice on this subject from anyone who hasn't actually done it.

Answer 5

In javascript:

Handling recurring schedules: http://bunkat.github.io/later/

Handling complex events and dependencies between those schedules: http://bunkat.github.io/schedule/

Basically, you create the rules then you ask the lib to compute the next N recurring events (specifying a date range or not). The rules can be parsed / serialised for saving them into your model.

If you have a recurring event and would like to modify only one recurrence you can use the except() function to dismiss a particular day and then add a new modified event for this entry.

The lib supports very complex patterns, timezones and even croning events.

Answer 6

You could store the events as repeating, and if a particular instance was edited, create a new event with the same event ID. Then when looking up the event, search for all events with the same event ID to get all the information. I'm not sure if you rolled your own event library, or if you're using an existing one so it may not be possible.