To clarify, this is all in reference to our "event" system. A customer
can create an event for March 3, 2006 as a one time event or a weekly
recurring event.
We are storing '2006-03-03' in the database as the "base date".
In order to find the date of the next event, we take the base date from
DB and add to that the increment value until the new base date is
greater than today's date:
$baseDate = from_db();
while($baseDate < $today)
$baseDate += increment
-Matthew
Zefram wrote:
Dave Rolsky wrote:
Pretty much all DBMS's (ok, not SQLite) have support for datetime as a
data type.
Worms. Can thereof. A datetime type is not a primary feature of a DBMS,
so it's probably not had much attention paid to it. Until recently,
MySQL's datetime type allowed dates such as 2006-04-31. Even if it's
implemented correctly, it'll implement some arbitrarily selected date
model that's not particularly likely to match your need. In this case,
timezone behaviour is the issue, and not very many datetime types handle
multiple timezones in the way desired.
Using a DBMS's datetime type also loses you portability, of course.
The advantage to this is that your datetime data is stored in a consistent
way, so if you ever need to compare datetimes for some reason, you know
that they'll compare sanely.
I think what he wants to store isn't actually a date, as in a point in
time. Looks like he wants to store a time of week, timezone-relative,
along with a timezone spec. The incrementing loop he came in with is
just answering the question "when will that time of week next occur?".
-zefram
