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
