Re: [db] MySQL 5.1 - Update/Insert logic fails on date-type columns

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [db] MySQL 5.1 - Update/Insert logic fails on date-type columns

Shekar C Reddy
The idea is to centralise the source of date-time info into one place. If the site is hosted with the application on one server and database on another (or multiple servers), their clocks might differ a bit. And some applications are time-sensitive to the second!
 
Regards,

 
 
 
On 5/13/06, Derick Rethans <[hidden email]> wrote:
On Fri, 12 May 2006, Shekar C Reddy wrote:

> But I want to insert the database-server time - not the web-server time.

But those should always be the same. NOW() and PHP's time() both return
a Unix timestamp. And Unix timestamps do not care about timezones.

regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Reply | Threaded
Open this post in threaded view
|

Re: [db] MySQL 5.1 - Update/Insert logic fails on date-type columns

GavinZend
I've worked on multiple projects that needed consistent times, did not
use NTP (except on their database servers), and did not synchronize
clocks on all their web servers.

Regarding the use of database functions within the ZF, I'm uncomfortable
with the idea of allowing unquoted entities to pass through methods that
normally quote.  This complicates code security audits.  If a flaw
elsewhere in an application allowed a hacker to alter the input to
bypass quoting, ...

Thus, I'd advocate making the developer provide a special case for when
certain input should not be quoted, and quote everything else by default
with an API optimized for the most common usage (quote-by-default).  I'm
already uncomfortable with the WHERE clauses in Zend Db not auto-quoting
.. more on that later.

--Gavin


Shekar C Reddy wrote:
> The idea is to centralise the source of date-time info into one place.
> If the site is hosted with the application on one server and database
> on another (or multiple servers), their clocks might differ a bit. And
> some applications are time-sensitive to the second!