You can set the value of the date. timezone key to 'Asia/Shanghai' in the urban configuration of the PHP script in PHP. ini. However, the shared VM itself does not have the permission to modify PHP. ini. At this time Program Add public part
Ini_set ('date. timezone ', 'Asia/Shanghai'); Modify the settings of PHP. ini dynamically. Then you can test whether the time is correct:
Var_dump (date (); If the local time of the server is correct, the problem is generally solved. Appendix: PhP 5.1 and above provide special functions to modify the corresponding time zone:
Date_default_timezone_set ('Asia/Shanghai'); we recommend that you use this function because it is more common. Corresponding to 'Asia/Shanghai', other available mainland time zones include Asia/Chongqing, Asia/Shanghai, and Asia/Urumqi (Chongqing, Shanghai, and Urumqi in sequence). Hong Kong and Taiwan regions are available: asia/Macao, Asia/hong_kong, Asia/Taipei (Macau, Hong Kong, and Taipei in sequence), Singapore: Asia/Singapore, and other available values are: ETC/GMT-8, Singapore, Hongkong, PRC; foreigners seem to have missed Beijing.
However, after I successfully modified the time zone on the PHP side, I found that the date was not properly recorded. At this time, I will consider whether it is a database issue. Sure enough, because the function inserted by the program does not call the PHP time, instead, it directly uses the MySQL currect_timestamp. In this case, you must consider whether you can modify the MySQL time zone.
Referring to the MySQL documentation, we found a feasible SQL statement:
Set global time_zone = '+ 8:00'; '+ 8:00' indicates the dongba district, and other urban areas are like this. I inserted a modified statement in the database model and found that the permission was insufficient (the damn VM provider ). Next, I debugged many statements, such:
Date_add (utc_timestamp (), interval 8 hour); displays the SQL statement of the time zone:
Show variables like 'System _ time_zone 'and so on. However, the restrictions on MySQL permissions do not provide a thorough solution. I Googled and found that foreigners have a very good solution. But he needs to modify the SQL statement of each inserted data. This solution is not very effective. Once the database time zone is changed to normal, the corresponding SQL statement will be changed back.
I think that since the PHP end can solve the problem of time correctly. Although the corresponding functions can be used for MySQL databases, it will be changed back if it is migrated to another host environment in the future. The corresponding field is of the timestamp type, and the default value is currect_timestamp. Of course, the time can be specified.
So my approach is to let PHP Insert the current correct time, although the program needs to be modified accordingly. However, you only need to modify the configuration once later. Note the format when inserting the database:
Date ('Y-m-d h: I: s') to solve the problem. Appendix, 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
updated: This wildgoose brother said he also encountered the same problem, but cannot solve. After various assumptions and judgments, I finally found the time zone configuration problem of Zend Studio (I am sweating ). In addition to the running environment, the development environment also needs to pay attention to the following.
I have encountered this problem today. I am lucky to be lucky enough to host my host. You can:
set global time_zone = '+';
Haha, unfortunately, you cannot use functions such as unix_timestamp.