On Sunday 26 January 2003 17:02, Paul Chvostek wrote:
So what's the best way to store a date? I've always liked storing epoch
seconds as INTs, and leaving the translation to/from a human-readable
date up to the application, but aside from the relative unreadability of
this, are there any significant disadvantages to this method, aside from
the rollover problem in 2038? (The S32b bug?)
Would I be better off spending a few bytes extra per record and storing
things as DATETIME rather than an INT? If I'm looking at the possibily
making the application more database-portable in the future, are there
gotchas I should be aware of with any particular field types?
I think it really depends on where you think you would be doing most of your
date manipulations. If most will be done within your SQL queries then use the
native DBMS date formats (as a plus MySQL has loads of useful date
functions). If your date stuff will mostly be done in PHP then use unix
timestamps.
On the whole I would stick to a DBMS native date format because:
- it's human readable
- built-in date functions
- not limited to post epoch dates
--
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design Hosting * Internet Intranet Applications Development *
/*
If Machiavelli were a hacker, he'd have worked for the CSSG.
-- Phil Lapsley
*/
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php