Anyone knows if there is such a function in MySQL?
UPDATE
This doesn't output any valid info:
mysql> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM | SYSTEM |
+--------------------+---------------------+
Or maybe MySQL itself can't know exactly the time_zone
used,that's fine, we can involve PHP
here, as long as I can get valid info not like SYSTEM
...
Try using the following code:
Insert a dummy record into one of your databases that has a timestamp Select that record and get value of timestamp. Delete that record. Gets for sure the timezone that the server is using to write data and ignores PHP timezones.
To get Current timezone of the mysql you can do following things:
Now if you want to change the mysql timezone then: 1. SET GLOBAL time_zone = '+00:00' //this will set mysql timezone in UTC 2. SET @@session.time_zone = "+00:00"; //by this you can chnage the timezone only for your particular session
select sec_to_time(TIME_TO_SEC( curtime()) + 48000); here you can specify your time differents as sec
Use LPAD(TIME_FORMAT(TIMEDIFF(NOW(), UTC_TIMESTAMP),’%H:%i’),6,’+') to get a value in MySQL's timezone format that you can conveniently use with CONVERT_TZ(). Note that the timezone offset you get is only valid at the moment in time where the expression is evaluated, since the offset may change over time if you have daylight saving time. Yet the expression is useful together with NOW() to store the offset with the local time, which disambiguates what NOW() yields. (In DST timezones, NOW() jumps back one hour once a year, thus has some duplicate values for distinct points in time).
From the manual (section 9.6):
Edit The above returns
SYSTEM
if MySQL is set to slave to the system's timezone, which is less than helpful. Since you're using PHP, if the answer from MySQL isSYSTEM
, you can then ask the system what timezone it's using viadate_default_timezone_get
. (Of course, as VolkerK pointed out, PHP may be running on a different server, but as assumptions go, assuming the web server and the DB server it's talking to are set to [if not actually in] the same timezone isn't a huge leap.) But beware that (as with MySQL), you can set the timezone that PHP uses (date_default_timezone_set
), which means it may report a different value than the OS is using. If you're in control of the PHP code, you should know whether you're doing that and be okay.But the whole question of what timezone the MySQL server is using may be a tangent, because asking the server what timezone it's in tells you absolutely nothing about the data in the database. Read on for details:
Further discussion:
If you're in control of the server, of course you can ensure that the timezone is a known quantity. If you're not in control of the server, you can set the timezone used by your connection like this:
That sets the timezone to GMT, so that any further operations (like
now()
) will use GMT.Note, though, that time and date values are not stored with timezone information in MySQL:
So knowing the timezone of the server is only important in terms of functions that get the time right now, such as
now()
,unix_timestamp()
, etc.; it doesn't tell you anything about what timezone the dates in the database data are using. You might choose to assume they were written using the server's timezone, but that assumption may well be flawed. To know the timezone of any dates or times stored in the data, you have to ensure that they're stored with timezone information or (as I do) ensure they're always in GMT.Why is assuming the data was written using the server's timezone flawed? Well, for one thing, the data may have been written using a connection that set a different timezone. The database may have been moved from one server to another, where the servers were in different timezones (I ran into that when I inherited a database that had moved from Texas to California). But even if the data is written on the server, with its current time zone, it's still ambiguous. Last year, in the United States, Daylight Savings Time was turned off at 2:00 a.m. on November 1st. Suppose my server is in California using the Pacific timezone and I have the value
2009-11-01 01:30:00
in the database. When was it? Was that 1:30 a.m. November 1st PDT, or 1:30 a.m. November 1st PST (an hour later)? You have absolutely no way of knowing. Moral: Always store dates/times in GMT (which doesn't do DST) and convert to the desired timezone as/when necessary.