On 21 Aug 2002, Robert Treat wrote: > On Tue, 2002-08-20 at 22:15, Mark Stosberg wrote: > > > > Hello Darrin, > > > <snip> > > > > I've been happy with this solution. I think the Perl turned out to be > > fairly easy to understand and maintain, the SQL that needs to be used > > ends up being fairly straightforward, and the performance is good > > because the selects to view the calendar are fairly simple. The one > > drawback is that sometime before 2028, I have to remember to add some > > rows to the calendar table. :) > > > > You need to add rows as well as re-populate a bunch of info for > recurring dates that are not listed forward right?
Perhaps this will answer your question Robert-- one point I didn't mention before is that I don't allow events events to recur forever, they have end after some finite number of times. You could add a birthday and tell it to repeat it once a year for the next 100 years for example. I wouldn't have to go and add rows for these later though-- the rows needed for the next 100 years would already be generated in the events_calendar table. The only thing that "expires" with my solution is the dates in the calendar table. I could make the dates run for the next 100 years just as easy as 28 years, I just figured the system would probably get a significant revamp sometime in the next quarter century. :) -mark http://mark.stosberg.com/ ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
