It's useful when looking at a list of shifts to know when the next time this shift will happen. Because we don't have this information in the database (yet) we have to calculate in ruby, which is generally slow. I was able to speed it up by creating a timeline with every shift in the view, then adding a new method to the timeline that would just get the next occurrence.
Even then, it's still about 3x slower. On my machine I measured ~120ms to load the page without, and ~380ms with. Reasonable, but not ideal. We hope this will get much faster in the future when we can calculate event occurrences in the database itself.
It also presents a problem for events in the far future. To keep the speed reasonable, we only calculate events out by one month. But if an event starts 1 year in the future, we still want to show it's next occurrence. We don't worry about events in the past, and we only support recurring events one month out.
If no next occurrence could be found, we create an occurrence based on the event's starts_at and use that, because that's the next time it will occur. This logic is wrapped up in a helper: link_to_next_occurrence_in_timeline.