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

Question

I would use a 'link' concept for all future recurring events. They are dynamically displayed in the calendar and link back to a single reference object. When events have taken place the link is broken and the event becomes a standalone instance. If you attempt to edit a recurring event then prompt to change all future items (i.e. change single linked reference) or change just that instance (in which case convert this to a standalone instance and then make change). The latter cased is slightly problematic as you need to keep track in your recurring list of all future events that were converted to single instance. But, this is entirely do-able.

So, in essence, have 2 classes of events - single instances and recurring events.

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. Read the linked article for more details about this.
• 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.

There can be many problems with recurring events, let me highlight a few that I know of.

Solution 1 - no instances

Store original appointment + recurrence data, do not store all the instances.

Problems:

• You'll have to calculate all the instances in a date window when you need them, costly
• Unable to handle exceptions (ie. you delete one of the instances, or move it, or rather, you can't do this with this solution)

Solution 2 - store instances

Store everything from 1, but also all the instances, linked back to the original appointment.

Problems:

• Takes a lot of space (but space is cheap, so minor)
• Exceptions must be handled gracefully, especially if you go back and edit the original appointment after making an exception. For instance, if you move the third instance one day forward, what if you go back and edit the time of the original appointment, re-insert another on the original day and leave the moved one? Unlink the moved one? Try to change the moved one appropriately?

Of course, if you're not going to do exceptions, then either solution should be fine, and you basically choose from a time/space trade off scenario.

You may want to look at iCalendar software implementations or the standard itself (RFC 2445 RFC 5545). Ones to come to mind quickly are the Mozilla projects http://www.mozilla.org/projects/calendar/ A quick search reveals http://icalendar.rubyforge.org/ as well.

Other options can be considered depending on how you're going to store the events. Are you building your own database schema? Using something iCalendar-based, etc.?

I'm working with the following:

• http://github.com/elevation/event_calendar - model and helper for a calendar
• http://github.com/seejohnrun/ice_cube - awesome recurring gem
• http://github.com/justinfrench/formtastic - easy forms

and a gem in progress that extends formtastic with an input type :recurring (form.schedule :as => :recurring), which renders an iCal-like interface and a before_filter to serialize the view into an IceCube object again, ghetto-ly.

My idea is to make it incredibility easy to add recurring attributes to a model and connect it easily in the view. All in a couple of lines.

---

So what does this give me? Indexed, Edit-able, Recurring attributes.

events stores a single day instance, and is used in the calendar view/helper say task.schedule stores the yaml'd IceCube object, so you can do calls like : task.schedule.next_suggestion.

Recap: I use two models, one flat, for the calendar display, and one attribute'd for the functionality.

I'm using the database schema as described below to store the recurrence parameters

http://github.com/bakineggs/recurring_events_for

Then I use runt to dynamically calculate the dates.

https://github.com/mlipper/runt