Pull a month of listings for a neighborhood with an active toddler dance class, and you've got two bad options. List every Saturday session individually, and that one class fills dozens of rows on a calendar that's supposed to represent a whole neighborhood's worth of things to do. Collapse it to a single entry for the first Saturday in September, and by October it looks like the class ended weeks ago, even though it's still running every week.
Neither one is exactly wrong. Both are true, technically. Both make the calendar worse.
I've built both versions, at different times, for different reasons that made sense in the moment. The first time, we wanted completeness: don't lose any information, show every date the organizer gave us. The second time, we wanted a clean list: don't let one popular class dominate the page. Both instincts were reasonable. Neither one, on its own, produced a calendar anybody would actually want to use for very long.
1. What goes wrong if you list every occurrence?
The class becomes noise. Someone scanning "this weekend near you" for the first time sees the same toddler class over and over, crowding out the market, the festival, and the other class that only runs twice a season. The person who already knows about the class doesn't need dozens of reminders that it exists. The person who's never heard of it is scrolling past yet another identical listing to find something new.
2. What goes wrong if you collapse it to one static entry?
The opposite problem: the class quietly goes stale. One listing, one date, and once that date passes, anyone looking at "what's happening this weekend" doesn't see it at all, even though it's still running. The organizer did nothing wrong. They set up a recurring class the way any recurring class works, and their listing disappeared from view anyway, because the calendar treated "recurring" as "happened once."
3. What does "the next date" solve?
We settled on one listing per series, shown by whichever date is actually coming up. A regular sees the same familiar entry they always see, in the same place, instead of a wall of duplicates. Someone new sees it exactly once, with a real, current date attached — not the class's first-ever session, not an outdated placeholder, but the next Saturday it's actually running.
That one design choice does two jobs at once. It keeps a weekly class from taking over a calendar that's supposed to represent everything nearby, and it keeps that same class from silently aging out of view the week after it started. A recurring class isn't one event and it isn't dozens of separate ones. It's a schedule, and the calendar should read like one.
4. What does this mean for how you'd use it?
If you're pulling class or camp data into your own product, the practical version of this is simple: expect one listing per series, not one row per date, and read occurrence.next_starts_local for the upcoming date, which moves forward as sessions pass. Don't build your own de-duplication step to collapse twenty-six near-identical rows, because you shouldn't be getting twenty-six rows in the first place. And don't cache a series' date once and assume it's still true next month — the same listing should keep telling you what's actually next.
That's a smaller integration than either extreme would have required, and it holds up whether the series runs for three weeks or three years.
Why this matters if you build on local data
Recurrence is one of the places local data quietly breaks if you model it too literally. Treat every occurrence as its own event, and popular recurring things drown out everything else. Treat a series as a single fixed record, and it goes stale the moment the first date passes. Either mistake makes a perfectly healthy, ongoing class look wrong on your calendar, through no fault of the organizer running it.