A little summary of PHP and MySQL time zones _php tips

PHP script side of the urban settings can be set under the PHP.ini date.timezone key value of ' Asia/shanghai ' can be. Typically, however, the shared virtual host itself does not modify php.ini permissions. This time it should be added to the public part of the program

Ini_set (' Date.timezone ', ' Asia/shanghai ') dynamically modify the settings of the php.ini. You can then test for the correct time:

Var_dump (date); If the server's local time is correct, the problem can generally be solved. Attached, PHP 5.1 above provides a special function to modify the corresponding time zone:

Date_default_timezone_set (' Asia/shanghai '); This function is recommended for more general use. corresponding to the ' Asia/shanghai ' other available Continental time zones also: asia/chongqing, Asia/shanghai, Asia/urumqi (Chongqing, Shanghai, Urumqi); Taiwan available: Asia/macao, asia/ Hong_Kong, Asia/taipei (Macao, Hong Kong, Taipei) and Singapore: Asia/singapore; Other available values are: etc/gmt-8, Singapore, Hongkong, PRC; foreigners seem to have leaked Beijing.

However, after I modified the success of the PHP side of the time zone found that the date is not correctly recorded. This time I consider whether it is a database problem. Sure enough, because the program inserted the function does not invoke PHP time, but directly using the MySQL Currect_timestamp. This time, consider whether you can modify the MySQL side of the time zone.

Referring to the MySQL documentation, a workable SQL statement was found:

SET GLOBAL time_zone = ' +8:00 '; The ' +8:00 ' is a representation of the East eight district, and the other urban areas in turn. And I'm inserting a change statement into the database model that doesn't have enough permissions (the damned virtual host provider). Next I debug a lot of statements, such as:

Date_add (Utc_timestamp (), INTERVAL 8 HOUR), display the SQL statement for the time zone:

Show VARIABLES like ' System_time_zone ' and so on. and due to the limitations of MySQL permissions There is no complete solution. I Google, found a foreigner this has a very good solution. But he needs to modify every SQL statement that inserts data. Such a scheme is not very effective, once the database time zone is changed to normal, then the corresponding SQL statement to be changed back.

And I think since the PHP side has been able to solve the problem of time correctly. MySQL database aspect may use the corresponding function to solve, but if later migrates to other host environment to change again. and the corresponding field is a TIMESTAMP type, the default value is Currect_timestamp, of course, you can specify the time.

So my practice is to get PHP to insert the right time, although the program needs to be modified accordingly. However, the configuration changes in the future as long as the modification of a place can be. Last time you insert a database note the format:

Date (' y-m-d h:i:s ') will solve the problem. Attached, some very good references:

Http://www.modwest.com/help/kb6-256.html
Http://topic.csdn.net/t/20060503/07/4728521.html
Http://www.phpchina.com/5173/viewspace_5132.html
http://www.phpx.com/pth110355.php
Update: From this wildgoose brother said he also encountered the same problem, but could not be solved. After a variety of assumptions and judgments, it turned out to be the Zend Studio's time zone configuration problem (i Khan ing). It seems that the development environment needs to be taken care of in addition to the operating environment.
Today I also encountered this problem, I am luckier than you, own host, can:
SET GLOBAL time_zone = ' +8:00 ';
Oh, you pity, can not use Unix_timestamp () such a function.