On Dec 3, 2007 7:37 AM, Emil Edeholt <emil@xxxxxxxxxxxx> wrote: > Hi, > > I'm about to add some simple calendar functions to my application, and > I'm thinking of how I should implement recurring events. Are there one > standard way most people use that works well? I guess you have some kind > of emitter event that creates the recurring events and a group id that > holds the events together. How long forward does one usually create the > events. Two-three years...? > > Sorry if I'm a bit blury. But any ideas on recurring events are welcome. > I guess I could just hack something together, but it would be fun to do > it right. > > Regards Emil > Emil, There is not much "simple" about a calendar, especially when you start dealing with recurring events. How far into the future your calendar allow events to recur will depend at least in part on how you intend to store them. For instance, you can store them in a database where you create a separate event row for each occurrence (though still be linked by a common ID as you said), but you'll probably set your limits based on storage to prevent adding a daily event for the next 10 years. You could also store a single event record that includes the rules for recurrence and then calculate the dates of each instance as needed, but that could get pretty CPU intensive. (I'm assuming you want to stick with "simple" periodic recursion, not more complex things like the date for Easter or events that don't have any set pattern.) Your decision will also be affected by whether you want to be able to modify a specific instance of a recurring event -- say to move your monthly meeting from 1:00 to 2:30 for next month only or to cancel your weekly card game 3 weeks from now without altering other instances of the same events -- will impact how you approach your design. And none of this takes into account the fun you get if you have to deal with multiple time zones and/or daylight saving time. For instance, if you store events in local time, you have to store the time zone with the record so you can convert from one time zone to another. If you store events in UTC, you usually have to account for shifts in daylight saving time so that your weekly 2:00 staff meetings don't suddenly change to 1:00. Then there are the occasional changes to the beginning/ending dates for DST like happened this year for the US. I know this probably muddies your original question even further, but I'll say again -- there is not much "simple" when it comes to calendars. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
