For a practical, real-world example of recurring calendar logic, look at your PDA or equivalent.
I got to build a calendar in an intranet application a few years ago and basically copied what my Palm had for recurring options. It made sense to people, so I judged it a success. But it didn't store real clean in the database. My code ended up with lots of careful checks that data was consistent along with various rules to correct things if something looked awry. It helped that we were actively using it as I was developing it. :-)
As far as storage went, the calendar entry involved a flag that indicated if it was part of a recurring series or not. If it wasn't, it was a non-recurring entry. If it was, then editing it had a couple of options, one of which was to break the series at this entry. Recurring entries were put into the database as discrete items; this was a type of denormalization that was done for performance reasons. Amongst other things, it meant that other code that wanted to check the calendar didn't have to worry about recurring items. We solved the "neverending" problem by always requiring an end-date to the series.
Actually setting up the recurring items involved some JavaScript in the UI to control the different settings. The entry in the DB had a combination of values to indicate the scope of the recurrence (e.g. daily, weekly, ...) the recurring step (e.g. 1 week, 2 weeks, ...) and any variation (weekly let you say "Monday, Wednesday, Thursday every week").
Finally, we had some logic that I never got to fully implement that handled timezones and daylight saving. This is difficult, because you have to allow the shift to apply selectively. That is, some calender items will stay in time local to the end-user, others are fixed to a location, and either may or may not shift with daylight saving. I left that company before I got a fix on that problem.
Lastly, I'm replying to this because I didn't see all the other questions. :-) But go read and understand that PDF.