Page 2 of 4

Posted: Wed Apr 11, 2007 4:25 pm
by Luke
I've read about 50 pages of the RFC, but nothing about dates and times yet. I guess it's time to skip to that part.

Posted: Wed Apr 11, 2007 6:51 pm
by TheMoose
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

Posted: Wed Apr 11, 2007 6:58 pm
by Luke
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. :D

Posted: Thu Apr 12, 2007 6:49 am
by feyd
If you have the individual rule entries in a separate table they could be queried quickly using a left/right join.

Posted: Thu Apr 12, 2007 9:25 am
by Luke
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?

Posted: Thu Apr 12, 2007 9:31 am
by feyd
Likely, an interesting join syntax. :)

Posted: Thu Apr 12, 2007 9:58 am
by Luke
yes, likely very interesting indeed. 8O

Posted: Thu Apr 12, 2007 4:20 pm
by Ambush Commander
For smaller calendars, the method of grabbing all recurring events in the database wouldn't be too far-fetched. Retrieving a 100 rows from the database is not too processor intensive.

Posted: Thu Apr 12, 2007 4:22 pm
by Luke
yes, but I'd like this to be fairly scalable.

Posted: Fri Apr 13, 2007 7:57 pm
by Ambush Commander
Then you may need to intentionally denormalize the database in order to improve performance. It's really hard to do this sort of optimization without actually having a working prototype.

Hows the RFC-reading coming along?

Posted: Sat Apr 14, 2007 8:00 pm
by programmingjeff
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).

Posted: Sun Apr 15, 2007 7:58 pm
by Ambush Commander
I think this would make a lot of sense as a caching system. It would still be most advisable to keep the original information the user entered, but this would be the fasted to retrieve dates from.

Posted: Mon Apr 16, 2007 9:15 am
by Luke
I think this would make a lot of sense as a caching system. It would still be most advisable to keep the original information the user entered, but this would be the fasted to retrieve dates from.
ambush, are you referring to programmingjeff's method?

Posted: Mon Apr 16, 2007 9:29 am
by Ambush Commander
Yeah.

Posted: Mon Apr 16, 2007 10:19 am
by Luke
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.

:D