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 

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

Reply via email to