On Fri, 3 Nov 2006, Zefram wrote:
OK, so you want the other behaviour. I suggest that instead of storing
an actual timestamp you should store a broken-down time: week number,
day of week, local time of day, and (most important) timezone rule.
You can put those together in DateTime to find out what point in time
they refer to. Increment the week number as required.
I don't think that's the best way to do it.
Pretty much all DBMS's (ok, not SQLite) have support for datetime as a
data type. I strongly recommend you convert all datetimes to the UTC time
zone, then storing that value. Then when you pull it out, convert it back
to the user's preferred time zone, which you can store as a string
("America/Chicago").
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.
Some DBMS's will let you store a datetime with a timezone, in which case
you can do that and store them in many different time zones, and stuff
still just works. In that case either solution is fine. I don't think
MySQL supports that though.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
