4 ms·

Here's a blog post we wrote on RRULEs that just highlights one part of why calendars are hard: https://nylas.com/blog/rrules/ https://nylas.com/blog/rrules/

by grinich 10y ago

faizshah 10y ago
I just started with with RRULEs using pg_rrule in postgres. How do you guys handle overrides and exceptions in your schema for the sync engine?
- priyadarshy 10y ago
  there's a lot interesting possibilities for you can handle this. for our sync engine at sunsama we've tried a few different approaches. currently, we store the "parent" recurring event as one document. then we store exception events as standalone one off calendar events that link back to the parent recurring event. unfortunately, we have to maintain two different types of exploded versions of recurring events (to handle notes on an instance). eventually, we added a bunch of extra fields to the parent event like a pointer to the next upcoming instance of this event and denormalized full list of exceptions so that we can more easily handle application logic like sending out reminders, and letting you use arrows to navigate b/w instance s of recurring events. so far with this approach of separating out the parents and children we've run into very few problems.
- helge5 10y ago
  I think DAViCal also used to process RRULEs directly within PostgreSQL, may be worth a look: https://gitlab.com/davical-project/davical https://gitlab.com/davical-project/davical
FragenAntworten 10y ago
The link to the rrule.js demo is broken; it has moved here: https://jakubroztocil.github.io/rrule/ https://jakubroztocil.github.io/rrule/
shaklee3 10y ago
There's a book called "Dreaming in Code" which actually details how hard this problem was for a real project that ultimately failed. Good book for anyone who wants to read an account of a writer who followed an entire software team through the lifecycle of a product.
- fmoralesc 10y ago
  I'll second this recommendation. For a shorter take on it, Joel Spolsky's review of the book[^1] is a nice read. [^1]: https://www.joelonsoftware.com/2007/01/21/the-big-picture/ https://www.joelonsoftware.com/2007/01/21/the-big-picture/
helge5 10y ago
If you do any serious calendar development, you should join CalConnect. This is where all the calendaring guys meet, work on the related RFCs (CalDAV, iCalendar) and do interoperability testing: https://www.calconnect.org https://www.calconnect.org Absolutely worth it.
- fjdlwlv 10y ago
  Calendaring gals too.
taneq 10y ago
Dates are one of those "way way harder than you think they are" topics.

Here's a blog post we wrote on RRULEs that just highlights one part of why calendars are hard: https://nylas.com/blog/rrules/ https://nylas.com/blog/rrules/

by grinich 10y ago

Here's a blog post we wrote on RRULEs that just highlights one part of why calendars are hard: https://nylas.com/blog/rrules/ https://nylas.com/blog/rrules/

faizshah 10y ago

I just started with with RRULEs using pg_rrule in postgres. How do you guys handle overrides and exceptions in your schema for the sync engine?

priyadarshy 10y ago
there's a lot interesting possibilities for you can handle this. for our sync engine at sunsama we've tried a few different approaches. currently, we store the "parent" recurring event as one document. then we store exception events as standalone one off calendar events that link back to the parent recurring event. unfortunately, we have to maintain two different types of exploded versions of recurring events (to handle notes on an instance). eventually, we added a bunch of extra fields to the parent event like a pointer to the next upcoming instance of this event and denormalized full list of exceptions so that we can more easily handle application logic like sending out reminders, and letting you use arrows to navigate b/w instance s of recurring events. so far with this approach of separating out the parents and children we've run into very few problems.
helge5 10y ago
I think DAViCal also used to process RRULEs directly within PostgreSQL, may be worth a look: https://gitlab.com/davical-project/davical https://gitlab.com/davical-project/davical

FragenAntworten 10y ago

The link to the rrule.js demo is broken; it has moved here: https://jakubroztocil.github.io/rrule/ https://jakubroztocil.github.io/rrule/

shaklee3 10y ago

There's a book called "Dreaming in Code" which actually details how hard this problem was for a real project that ultimately failed. Good book for anyone who wants to read an account of a writer who followed an entire software team through the lifecycle of a product.

fmoralesc 10y ago
I'll second this recommendation. For a shorter take on it, Joel Spolsky's review of the book[^1] is a nice read. [^1]: https://www.joelonsoftware.com/2007/01/21/the-big-picture/ https://www.joelonsoftware.com/2007/01/21/the-big-picture/

helge5 10y ago

If you do any serious calendar development, you should join CalConnect. This is where all the calendaring guys meet, work on the related RFCs (CalDAV, iCalendar) and do interoperability testing: https://www.calconnect.org https://www.calconnect.org Absolutely worth it.

fjdlwlv 10y ago
Calendaring gals too.

taneq 10y ago

Dates are one of those "way way harder than you think they are" topics.