I am confused too Adrian as to which one are you advocating? I have always wondered why we used UNIX timestamps while there are database native types for date and time. Over time, I got used to the timestamp things, and it does not bother me much anymore. I wrote some primitive routines to handle FormAPI to timestamp and vice versa. function fapi2date($date = array()) { return strtotime($date['year'] . '-' . $date['month'] . '-' . $date['day']); } function date2fapi($date) { if (!$date) { $date = time(); } $fapi_date = array(); $fapi_date['year'] = date('Y', $date); $fapi_date['month'] = date('j', $date); $fapi_date['day'] = date('d', $date); return $fapi_date; } I still miss the ability to handle dates in the back end in queries though. On 3/5/06, Robert Douglass <rob@robshouse.net> wrote:
So wait, you're confusing me. Which approach are you advocating? Db handled date/times, or timestamp()/PHP handled??? Adrian Rossouw wrote:
On 05 Mar 2006, at 11:22 AM, Bèr Kessels wrote:
I think nearly all modules out there should try to rethink how / if they would be if they were nothing more then bunch of a: Views and CCK definitions, Views and CCK extensions and custom logic.
Yup.
since we are doing the date type stuff now properly.
how about we consider moving to actual in-database date fields instead of using timestamps.
i quite like being able to use the database for my date handling. Truth be told, that is before I started using strtotime (which is by far the most useful function in php's date handling lib), and was dissillusioned at how horrible mysql's date handling is compared to postgres.