---
layout:    post
title:     "Recurring events are hard"
date:      2018-07-19 13:22:00
tags:      [development]
published: true
author:
    name: Gergely Polonkai
    email: gergely@polonkai.eu
---

It was almost a month ago when I
[announced]({% post_url 2018-06-26-please-welcome-calendar-social %}) the development of
Calendar.social.  Since then I’m over some interesting and some less interesting stuff; (web)
development, after all, is just a recurrence of patterns. Speaking of recurrence, I arrived to a
really interesting topic: recurring events.

My initial thought was like “oh, that’s easy!  Let’s insert all future occurences as a separate
`Event` object, linking to the original one for the details.  That makes handling exceptions easy,
as I just have to update/delete that specific instance.”  Well, not really.  I mean, an event
repeating daily *forever* would fill up the database quickly, isn’t it?  That’s when I decided to
look how other projects do it.

As it turns out, my first thought is about the same as everyone else has their mind, with about
the same reasons.  Then, they usually turn down the idea just like I did.  And instead, they
implement recurrence patterns and exception patterns.

My favourite is
[this article](https://github.com/bmoeskau/Extensible/blob/master/recurrence-overview.md) so far.
The author suggests to use the recurrence patterns specced by
[RFC2445](http://www.ietf.org/rfc/rfc2445.txt) (the spec for the iCalendar format).  The
interesting part in this solution is how to query recurring events: you simply store the timestamp
of the last occurence of the events (or, if the event repeats forever, the greatest timestamp your
database supports.)

Choosing the maximum date seemed to be the tricky one, but it turned out both Python and popular
SQL backends support dates up to the end of year 9999.