Complete.Org: Mailing Lists: Archives: discussion: April 2004:
[aclug-L] Re: mysql, timestamps and timezones (oh my)

[aclug-L] Re: mysql, timestamps and timezones (oh my)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: discussion@xxxxxxxxx
Subject: [aclug-L] Re: mysql, timestamps and timezones (oh my)
From: Jesse Kaufman <glandix@xxxxxxxxxxxx>
Date: Tue, 13 Apr 2004 15:13:04 -0500
Reply-to: discussion@xxxxxxxxx

On Tue, 2004-04-13 at 09:27, Donald King wrote:
> There's another benefit, too.  If you just create your field as a plain ol' 
> INT UNSIGNED, you can use the MySQL built-in function UNIX_TIMESTAMP() to get 
> the server-side time.  This is *extremely* handy if you, say, have multiple 
> webservers but one database, and the webservers don't synchronize their 
> clocks with NTP.

until i found out i had to build in tz support, i'd been using CURTIME()
anyway (some of the pygtk clients in our warehouse were having problems
keeping time even w/ ntp enabled, so datestamps would be WAY off) ...
that IS very handy! :)

ok, stupid question: the result of UNIX_TIMESTAMP() ... are unix
timestamps always UTC/GMT time?  ie UNIX_TIMESTAMP() on a server in CST
== UNIX_TIMESTAMP() on a server in EST ...

anyway, i have def decided to use the unix timestamp stored in an INT()
method for storing dates ... sounds much easier than screwing with
figuring out the difference b/n localtime of the tz the server is in and
localtime of the tz a client might be in ...

thx for the help,

They called me chicken legs, they called me four-eyes
they called me fatso, they called me buckwheat,
they called me Eddie..."
        'Grade 9' - Barenaked Ladies

-- This is the discussion@xxxxxxxxx list.  To unsubscribe,

[Prev in Thread] Current Thread [Next in Thread]