Brenton Alker-3 wrote:
>
> solve.
>
> 1. How would I persist this information?
> The start date is easy, it's just a date.
> The interval I'm not sure about. A number of seconds (or days if it's
> only accurate to date) could work for basic things like every week. But
> what about irregular things like every month, or even more complex
> values eg. "The first Sunday of the month"?
>
If the timespans are really complex, in essence: can not be catched in a
limited amount of time values, you will always need to have an algorithm
that designates the interval.
So I would associate constants to those algorithms. In many databases you
can create enumerated types for example.
event_interval: {FIRST_MONDAY_MONTH, FIRST_TUESDAY_MONTH, FIRST_DAY_YEAR,
etc}
store an event like: "My event", "John", "2009-08-21", FIRST_MONDAY_MONTH
In your logic, be it php or a self written mysql function for example, you
would get the actual value based on the interval constant.
Simple things like "next saturday", "+1 month" are understood by php date
functions (http://php.net/manual/en/function.strtotime.php)
$d = new DateTime('next saturday');
echo $d->format('d, F Y'); //works!
I think you might even be able to bypass the constants if you would have a
interval scheme like this
table: interval_when
year, month, week_year, week_month, day_month, day_week
----------------------------------------
null null null null null 7
==> means: every sunday
2009 null null null null 7
==> means: every sunday in 2009
null null null 1 null 7
==> means: every first sunday of the month
Translating a record from this to an actual date might require one generic
function.
--
View this message in context:
http://www.nabble.com/Finding-%22next%22-date-for-an-event-tp25993104p26041198.html
Sent from the Zend Framework mailing list archive at Nabble.com.
