I've gone down this road with a calendar application, and ended up deciding to store each instance of an event in the database.
For this part of the application, there were two tables... one to store event information (title, description, etc.), and one for each instance of it (id, start date/time, end date/time, etc.).
The downside is that events really must end at some point in the future, whether that is a month from now, or 50 years from now. You could pick an arbitrary date in the future for "infinitely recurring" events, but that depends on your application whether or not this is appropriate.
The upsides are plenty. You get fast access to dates/times of events without having to calculate it on the fly... it's already in the database! It makes the rest of your code very simple.
The route you choose is up to you, but I've found that by keeping it simple and fast, everyone was quite pleased.