A model with changing parameters (recurring event calendar)
Moderator: General Moderators
4.3.4 Date
Format is YYYYMMDD (ie: 20070411)
4.3.5 Date-Time (YYYYMMDDTHHMMSS)
19970714T133000 - Local time
19970714T173000Z - UTC time
TZID=US-Eastern:19970714T133000 - Local time and time zone reference
4.3.10 Recurrence Rule
Example in the RFC:
10 occurrences every other day:
FREQ=DAILY;COUNT=10;INTERVAL=2
Format is YYYYMMDD (ie: 20070411)
4.3.5 Date-Time (YYYYMMDDTHHMMSS)
19970714T133000 - Local time
19970714T173000Z - UTC time
TZID=US-Eastern:19970714T133000 - Local time and time zone reference
4.3.10 Recurrence Rule
Example in the RFC:
10 occurrences every other day:
FREQ=DAILY;COUNT=10;INTERVAL=2
cool, then I guess it's a matter of reading the RFC and duplicating iCal. The tricky part is going to be exactly what Ambush Commander said. How will I query for dates in November if the event starts in January, but recurs in November without querying ALL recurring events and dissecting them with PHP? Doing it that way seems very resource intensive.
The cool thing about doing it like this though, is that it will make exporting to an ical file a breeze.
The cool thing about doing it like this though, is that it will make exporting to an ical file a breeze.
yea but the issue is how to find out if a recurring event will fall on a certain month without selecting ALL recurring events and then doing the calculations. For instance if there is a weekly recurring event that happens once every five weeks, on thursday starting in January, and ending October 4th, how do you know whether or not to SELECT this event from the database if the month is July?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
-
programmingjeff
- Forum Commoner
- Posts: 26
- Joined: Fri Jan 05, 2007 10:56 am
I apologize that I have not read the RFC, which may completely blow away my idea. I also realize that it would take some effort to export this type of backend to sunbird/iCal....
When I created a MySQL-based calendaring system, I created a separate field for each event called "reoccuringid". Every time a reoccuring event was created, it would generate every event in the series as normal events, but these events would have the same "reoccuringid". This enables you to modify/delete an individual event in the group without modifying the entire group.
You could then have the column link to another table, which would hold every reoccurance group, and all associated information (repeat frequency, etc).
The major advantage of this method is that you don't have to have special code to fetch/display reoccuring events when trying to show all of the events in a month, because reoccuring events are stored the same way as non-repeating events.
The major disadvantages include lack of support for infinitely repeating events (although I assumed that events wouldn't need to repeat for more than 10 years), and you would have to do some modification when trying to export to Sunbird/iCal (I'm not exactly sure how they handle these events).
When I created a MySQL-based calendaring system, I created a separate field for each event called "reoccuringid". Every time a reoccuring event was created, it would generate every event in the series as normal events, but these events would have the same "reoccuringid". This enables you to modify/delete an individual event in the group without modifying the entire group.
You could then have the column link to another table, which would hold every reoccurance group, and all associated information (repeat frequency, etc).
The major advantage of this method is that you don't have to have special code to fetch/display reoccuring events when trying to show all of the events in a month, because reoccuring events are stored the same way as non-repeating events.
The major disadvantages include lack of support for infinitely repeating events (although I assumed that events wouldn't need to repeat for more than 10 years), and you would have to do some modification when trying to export to Sunbird/iCal (I'm not exactly sure how they handle these events).
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
so programmingjeff's system would be a caching system? I guess that makes sense to call it that. I think that if the system entered in 10 years of events, that would be plenty, because it is highly unlikely that this system will still be in place, in its present form, in ten years. That is forever in software time. Any advice on how to make this as bullet-proof as possible? Thanks for the advice so far, it's been extremely helpful.
