views:

100

answers:

2

Say I have multiple servers in multiple locations and I want to use MySQL's datetime type for the field date and I always want to have the field date have the UTC timestamp so I would execute a UTC_TIMESTAMP() when I add it to the database. Now say I want to have MySQL output the UNIX TIMESTAMP for it.

When I do this on Server A I get the string "2009-06-17 12:00:00" doing the UNIX_TIMESTAMP(STRING) on it gives me the number 1245240000 back. Which is 2009-06-17 12:00:00 in UTC time. Now I do the same thing on Server B. I get the same string back since its the UTC string but when executing UNIX_TIMESTAMP(STRING) again I get back the wrong number back 1245232800 which is the UTC +2 time. How do I get around this? Should I do the convertion from string to timestamp on the PHP side?

+1  A: 

G'day,

I'll ask the obvious here, did you check the date and time on both machines?

Edit: ... and the MySQL timezone was the same on both machines?

Update: Ok. The problem is in the fact that the timestamp string being passed into UNIX_TIMESTAMP is interpreted to be a value in the current timezone which is then converted back to UTC so, because you're in MEZ, two hours is subtracted to return it back to UTC so 7200 is subtracted from your timestamp when it is converted back to a Unix timestring.

Hence, the variation you see when using UNIX_TIMESTAMP() to convert is back to a Unix Epoch timestring.

BTW Shouldn't you be using a TIMESTAMP type for storing off your UTC_TIMESTAMPs instead of DATETIME type?

Update: Decoupling presentation time from stored time is definitely the way to go. You can then reuse the same data all around the world and only have to convert to and from local time when you are presenting the data to a user.

If you don't do this then you are going to have to store off the timezone when the timestamp was made and then go into all sorts of complicated permutations of having to work out if

  • the local timezone was in daylight saving time when it was stored,
  • what the difference is between the timezone at the time that the data was stored and the timezone where the data is to be presented.

Leaving it all storeed as UTC gets rid of that.

Most users won't be that happy if they have to work out the local time themselves based on the UTC time returned so systems usually convert to current local time for the user.

This is of course if the user wants the data expressed in local time which is usually the case. The only widely used system I can think of, off the top of my head, that stores and presents its data in UTC is system for air traffic control and flight plan management which are always kept in UTC (or ZULU time to be more precise).

HTH

cheers,

Rob Wells
the one is set to utc time and the other to UTC+2 because the one machine is in London and the other one is in germany.. I always want to have the locale timezone set as the timezone because thats what other people suggest http://serverfault.com/questions/14685/local-timezones-on-servers-considered-harmful
Thomaschaaf
@Thomas, definitely stick with keeping internal time representation as UTC! Decoupling, stored values from prenetation values is the only way to go,
Rob Wells
so why are they saying to keep it at the localzone then?
Thomaschaaf
A: 

Have you tried doing this?

Execute this instructions together.

SET time_zone = 'UTC';
SELECT FROM_UNIXTIME(0), UNIX_TIMESTAMP('2009-06-17 12:00:00'); 
// 1970-01-01 00:00:00        1245240000

They only affect the client session, not the server configuration.

Kiewic