• Summary
• iCalendar specs
• Supporting Libraries
• Real-World Samples
• Modeling, Controlling, Viewing, and Editing Recurring Events
• Master Event
• UI for Master
• Instances
• Generating Instances
• Tentative Events
• “Pending” or “Tentative” events
• On event listing pages
• On Show Page
• Edit Page
• Export / Feeds
• Other

Summary

This file contains notes and ideas for implementing recurring events in Calagator

iCalendar specs

We are focusing on the iCalendar specification for recurring events because (1) it's complete, and (2) popular calendar systems (Google Calendar, Upcoming, Outlook) use it.

iCal specs for recurring events are here: http://tools.ietf.org/html/rfc2445#section-4.8.5

The iCal spec is rich, but popular calendars seems to implement only part of it: RRULE and EXDATE

RRULE http://tools.ietf.org/html/rfc2445#section-4.8.5.4 is a rule for when the event should recur. The iCal spec allows multiple RRULEs for an event, but Google Calendar seems to generate only one.

EXDATE http://tools.ietf.org/html/rfc2445#section-4.8.5.1 is a list of date/time exceptions. Example:

EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z

You cannot create exceptions at the time that you create a recurring event in Google Calendar. Instead, you create exceptions by editing one of the occurrences. Google has a delete option with these choices: delete this occurrence, delete all future occurrences, delete all occurrences.

Supporting Libraries

Vpim turns out to have so many problems that it is not practically usable for recurring events. For instance Vpim does not import EXDATE properties, creates an RRULE when none exists, does not exposes the details of RRULE objects.

Fixing Vpim would be so difficult that we decided to first explore the possibility of finding and using another library such as: lib iCalendar, library used by Mozilla for Thunderbird and Sunbird/Lightning, Darwin, something newer available in Ruby.

In addition to supporting EXDATE and RRULE, it's desirable for the library to support event locations and tags.

VObject is a Python package for parsing and generating vCard and vCalendar files. We might be able to port this Ruby.

the Runt Ruby Gem - an implementation of select temporal patterns. This is a possible format for Calagator's internal representation of recurrence.

Real-World Samples

• Rails code for recurring event generator Uses Runt. (Although this blog post says "recursive" generator, it probably should be "recurring").

Modeling, Controlling, Viewing, and Editing Recurring Events

Recurring events should have a master event plus instances. Generate instances only for the next three months, and mark each as tentative. See Tentative events below. A periodic task will later generate later instances (also marked as tentative), so that Calagator always shows 3 months' worth of instances.

Master Event

Master should include

• Rules needed to generate instances. This should include start date, end date and/or count, RRULE, EXDATE
• Perhaps also keep the date of (or id of?) last instance generated
• How to deal with a deleted instance? One possibility is simply adding it to EXDATE.

UI for Master

Some ideas are at

• a working link to a repeat event input widget for calagator

• Recurrence.png
• usability study for handling repeating events in calagator

Instances

• Keep ID of master
• Include field that marks the instance as tentative, confirmed (or canceled?)

Generating Instances

When a recurring event is first created, it should create three months of instances, and mark each one as tentative.

A task that is run periodically creates any instances that occur after the first 3 months.

If the periodic task is run daily it will create 1 instance at most.

For each master event that has not expired (this is easy to tell if there's an end date, but harder if there is a set number of instances; perhaps we want an expired field),

calculate the date of the instance that is after the last instance previously created, if that date is within 3 months and is not an exception (EXDATE), create an instance with that date

Tentative Events

“Pending” or “Tentative” events

These are automatically generated recurrences of imported event

Need an extra field to indicate that this is tentative. Possibly have different display for tentative events that were generated from a recurring event without a recently confirmed instance.

On event listing pages

Possibly display event in different color. Possibly add extra line saying that event is tentative/automatically generated.

On Show Page

Add information that gives user idea how stale date is, such as when master was generated, when an instance was last confirmed.

Edit Page

Should ask whether user is editing just this instance or all recurrences

Need way to confirm that event is indeed occurring (possibly just turn off tentative field); This should be a check box (for the single event).

We need a way to handle this differently from other edits. For instance, we may want to apply an edit (e.g., change of location) to all future instances, but we should not allow users to confirm all future instances.

Possibly allow people to confirm the next few events (or events in a a given time period like the next few months).

Export / Feeds

???

VEVENTs have STATUS property which can be TENTATIVE, CONFIRMED, or CANCELLED. It's not clear how well supported this is. ICS files exported from Google Calendar do set this property. ICS files exported from Upcoming do not include this property.

Other

Gardening tool -- we'll probably want a way to review "stale" events. "Stale" means recurring events that have not had a confirmed event in (period of time to be determined).

Suggestion: Display list of such events with Delete / Confirm / Skip radio buttons for batch updates.