Simple practical usable PHP logic for recurrence - php

Question

I have submitted this previously but because someone down voted it and said it was already answered, no-one will answer it.
I know there are similar posts here:
Design question: How would you design a recurring event system?
What's the best way to model recurring events in a calendar application?
but they do not answer my request which is for a practical, simple and real-world example of logic for a recurring calendar setup, without using another framework or tools/scripts other than straight PHP and MySQL.
I do agree that this article http://martinfowler.com/apsupp/recurring.pdf is good, but it is so abstract that I cannot understand it.
I know there are other "Systems that have done this" but this is my own white whale, and I will figure it out at some point - I would just like some help along the way.
So, the question is: how do I build a recurring calendar using PHP and MySQL?

Answer 1

You should strive to understand the Fowler article. It really does cover it.
The fact of the matter is, this is a hard problem. Editing logic "on the fly" is not something users really want to do. Rather, they want you as a programmer to have anticipated what they'll want to do and provided a rule for it--they don't want to have to figure out how to compute the second Wednesday of the month, for instance.
It sounds like your real problem lies in modeling the recurrence in MySQL. You could use Google's spec, which can be stored in a database and covered on Stack Overflow before. Fowler's piece also provides some good starting points in terms of well-defined classes that can be represented in an RDBMS.
It's a hard problem. And while SO wants you to succeed, we can only lead you to the stream. We can't force you to drink.

Answer 2

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.