I think it would be cleaner and clearer to simply find a way to record which update had completed and check that before running the update. Checking the column type is always going to be problematic. Better to avoid that specific issue altogether.
..chris On Thu, May 14, 2009 at 2:51 PM, Nancy Wichmann <[email protected]> wrote: > mark Burdett wrote: >> If you do use format_date() to put dates in the database make sure you > give it a time zone to use, otherwise you will end up >> with datetimes in different time zones depending on the current user's > configured time zone. > > Thanks, Mark. In my case, it is the server (hook_cron) that is creating > these dates, so the timezone doesn't matter. > > I just decided to use "date('Y-m-d H:i:s', $now)" where $now is set from the > PHP 'REQUEST_TIME' value. > > Nancy E. Wichmann, PMP > Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]]on Behalf Of mark burdett > Sent: Thursday, May 14, 2009 2:48 PM > To: [email protected] > Subject: Re: [development] DB Column Format > > On Thu, May 14, 2009 at 11:07 AM, Nancy Wichmann <[email protected]> > wrote: >> Next question: Is there are Drupal or database-independent date formatting >> function that produces a DATETIME value. I know I can use date() with >> something appropriate, but I don't know how efficient that is. > > using PHP functions like gmdate() should always be more efficient, > because these functions (or, date_create() and date_format() in drupal > 7) are what format_date() uses anyways. Multiple times in fact.. it's > a rather slow function if you benchmark it. > > If you do use format_date() to put dates in the database make sure you > give it a time zone to use, otherwise you will end up with datetimes > in different time zones depending on the current user's configured > time zone. > >> Would there be any interest in my submitting a patch for > "format_date($time, >> 'datetime')?" > > If this patch gets committed http://drupal.org/node/325827 then date() > function will also work in the current user's time zone, not the > server-wide time zone, so it wouldn't be useful for inserting dates in > the database or generating date-based URL path components that should > not vary depending on the current user's time zone. I might be > interested in a helper function that generates dates in the site-wide > default time zone, otherwise developers will be doing this which is > pretty verbose for getting a date: format_date($timestamp, 'custom', > $format, variable_get('date_default_timezone', > date_default_timezone_get()), 'en') > > --mark > > > No virus found in this outgoing message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.12.29/2114 - Release Date: 5/14/2009 > 6:28 AM > >
