Simple practical usable PHP logic for recurrence

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:

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?

I won't downvote you, but your question is so abstract that I cannot understand it :) What is that you wanted to ask, for first? — Quassnoi
– Quassnoi, Commented Feb 27, 2009 at 14:14
the question is, how do I pull dates from a database, and if (is set to m-w-f) show it on just those dates, unless there is a date that matches in a "exclusion"table then show it... what about other recurrance patterns.... 1st _day of month etc — Tim
– Tim, Commented Feb 27, 2009 at 14:26

Jeremy DeGroot · Accepted Answer · 2009-02-27 14:18:38Z

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.

answered Feb 27, 2009 at 14:18

Jeremy DeGroot

4,4962 gold badges24 silver badges21 bronze badges

Sign up to request clarification or add additional context in comments.

8 Comments

Tim Over a year ago

I started as a ADD Visual designer, not coder so fowler's examples are way over my head... is there anything that can help me understand fowler?? an intermediary if you will??

Jeremy DeGroot Over a year ago

Where do you feel like you fall short in your understanding? Are you not familiar with OO principles? Are the UML diagrams foreign to you? Or are there particular concepts that you don't fully grok? Asking about those specific things would help us help you.

Tim Over a year ago

Well, i guess the real issue is, most problems I encounter or scripts I need to create involve taking something that is working and fiddeling with it till it breaks, then I fix it and modify it to my needs for that moment -- I guess that would mean I don't "Understand" any of it [;o)

Tim Over a year ago

example - public boolean isOccurring(String eventArg, Date aDate) { ScheduleElement eachSE; ... I get the basic "Idea" of what the pieces are, but don't know what data or veriables go where and how to make it all work together

Jeremy DeGroot Over a year ago

I would recommend editing your question to focus on those aspects of the Fowler paper, then. You'll get more help with specific questions than the somewhat vague and difficult one you posed.

|

staticsan · Accepted Answer · 2009-03-01 23:57:44Z

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.

Collectives™ on Stack Overflow

Simple practical usable PHP logic for recurrence

2 Answers 2

8 Comments

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

8 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Related