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

[Jeff Vian <jvian10@xxxxxxxxxxx>]

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,
>-g-
>  
>
 From the documentation.

|UNIX_TIMESTAMP()|

|UNIX_TIMESTAMP(date)|
    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,
visit http://www.complete.org/cgi-bin/listargate-aclug.cgi