[aclug-L] Re: mysql, timestamps and timezones (oh my)
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Jesse Kaufman wrote:
>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,
From the documentation.
If called with no argument, returns a Unix timestamp (seconds since
|'1970-01-01 00:00:00'| GMT) as an unsigned integer. If
|UNIX_TIMESTAMP()| is called with a |date| argument, it returns the
value of the argument as seconds since |'1970-01-01 00:00:00'| GMT.
|date| may be a |DATE| string, a |DATETIME| string, a |TIMESTAMP|,
or a number in the format |YYMMDD| or |YYYYMMDD| in local time:
look that up on the documentation that came with your distro.
"/usr/share/doc/mysql-3.23.54a/manual.html" on my system.
-- This is the discussion@xxxxxxxxx list. To unsubscribe,