Originally posted by maybl8r03
IMHO, date types in database are a huge concern for portability. Especially when the products we produce have to adhere to our client's db requirements not ours. I tend just to use the ISO date in a varchar or char datatype.
The standard date format of YYYYMMDD will sort quite happilly - using character sorting or numeric sorting.
To set it is simple. Simply do date("Ymd")
To retrieve it is slightly more complicated but it's worth the extra "magic" function - strtotime() :
$strDateFromDB = "20030929";
$strUserView = date("d M Y", strtotime($strDateFromDB));
[/B]
Sorry, but I'm gonna disagree here.
timestamp is a SQL 92 standard type. It's been around a long time, and every decent database I've ever played with has it as a type.
If you are forced to work with a database that doesn't understand what a timestamp type is, then that database vendor needs to get their stuff together and fix the underlying problem.
I've dealt with many different databases (Postgresql, Oracle, MSSQL, Informix, Ingres, db2) and they ALL understand date/time types quite well, and it's usually very easy to port back and forth. Other than MySQL insisting on calling an auto-timestamp column timestamp, and then making a new type called datetime (or whatever they called it) MySQL also works quite well with dates.
Further, storing your dates as text makes it very hard to make sure they are proper dates. One could easily enter the 30th of February or the 35th of December and the database would never stop them.
Also, if you need a constraint (i.e. the bill date must be later than the contract date etc...) then it's much more difficult to write such constraints if the date is stored as text, and such checking presents a higher load on the CPU.
date/time types, implemented properly, are a huge win for data consistency, and data consistency is the primary reason for using a database and not a flat file.