A really essential element in any kind of personal information manager is a recurrence pattern.  You know: “every 3 days”; “at the beginning of the month”; “2 weeks after I’m done.”

For some kinds of PIM apps — habit managers come to mind — you might even say that the richness of the recurrence pattern repertoire is the main element driving me to pick one over the other.

The problem is that doing recurrence patterns is hard, and doing them right is even harder.  They are perverse.

Recurrence patterns inherit at least some of their perversity from the calendar itself.  We have years that don’t divide into weeks.  We have months that don’t divide into weeks either, and that don’t even have a uniform length.  We have weekdays and weekends.  We even have different clocks, since our legacy clock the Earth is slowing down.

(Scientists add a second to the year every few years.  I have this picture of a team in white coats bringing over a bar of light a light-second long and opening an access cover and throwing into the stream of light that is Time.  Given how long a light-second is, that’s a pretty big team.)

But then the nature of recurrence adds some extra perversity all its own.

In the first place, some recurrences are regular and some are driven by completion of the event.  “Every two days” is not the same as “two days after I finish.”

And some recurrences have more oomph (a technical term!) than others: you’ve got to take your medicine every day, you ought to exercise every day (but the sky won’t fall if you don’t), and it would be nice to write a handwritten thank-you note after every dinner party.

(Perhaps the oomph is best handled not in the recurrence mechanism itself but in a orthogonal priority or urgency mechanism.  Even so, it would be nice to express the oomph at the same time you created the recurrence pattern (but see Syntax and Command Language below).)

And then, as if the foregoing weren’t enough, some recurrences are fuzzy.  “Every 2-3 days.”  “4 times a week max.”

I once used a habit manager app for a few months just because it had some cool fuzzy recurrence features.  It didn’t interoperate with anything else, it only ran on iOS, and it didn’t sync with the cloud — all flaws that eventually drove it down.  But those fuzzy recurrences were pretty cool: I miss them still.

So these are variety issues.  Recurrence patterns are hard in part because of the variety.

But there are (at least?) three issues with recurrence patterns aside from their variety:

1. Controller interface.  A lot of recurrence providers try to offer a natural-language interface to recurrence patterns.  “Just type in a phrase that describes when your task has to be done”.    I’m not blown away by these (and I’m an old NLP guy from the ’80s).  You really can’t say what you mean often: “The 2nd Saturday of each month” may well parse to “every other Saturday” in one system and to its intended meaning in another.  Having a form to fill out is better, because you can at least see all the options that can be generated, but forms don’t do well with fuzzy recurrences.
2. Internal Representation.  Whatever the implementation of a task or an event, a recurring task or event is a different kind of animal: it’s not a data structure, it’s an object.  Outlook, for example, doesn’t even seem to store recurring objects in the same file as task or calendar objects.  When you migrate, they don’t always migrate together.
3. “Round Trip”.  The different representations of recurring objects means that at some point they will need to “compile” to their non-recurring cousins.  One would want this to be a round trip in the sense that you could traverse from the recurrence to the end objects and also reconstitute the recurrence from the end objects.  No one does this.  Once a recurring object has been instantiated, there’s no going back.

For all these reasons, recurring patterns are hard, and getting them right is an architectural key to a great PIM.