Add article about recurring events

_posts/2018-07-19-recurring-events.md

@@ -0,0 +1,37 @@
+---
+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.