Due to the temporary use of foreign space, I published a Blog when I found that time is always wrong. This is a time zone problem, based on my previous experience writing programs. This problem is not difficult to solve, write down my solution for future reference.
The PHP script side of the urban settings can be set under PHP.ini date.timezone key value of Asia/shanghai can be. However, generally the shared virtual host itself does not modify php.ini permissions. Ini_set (Date.timezone,asia/shanghai) should be added to the public part of the program at this time; Dynamically modifies the settings of the php.ini. You can then test whether the time is correct: var_dump (date ()); If the local time of the server is correct, then the problem will be solved in general. 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 because it is more generic. Corresponding Asia/shanghai other available continental time zones are: asia/chongqing, Asia/shanghai, Asia/urumqi (Chongqing, Shanghai, Urumqi, respectively); 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; the foreigner seems to have leaked Beijing. However, after I modified the time zone of the successful PHP end, the date was not recorded correctly. This time I consider whether it is a database problem. Sure enough, because the program inserted function does not call PHP time, but the direct use of MySQL currect_timestamp. This time, consider whether you can modify the MySQL time zone. Referring to the MySQL documentation, a workable SQL statement was found: SET GLOBAL time_zone =; Which is the East eight district of the expression method, the other urban areas in turn. And I inserted the change statement in the database model to find that the permissions are not enough (the damned virtual hosting provider). Next I debug a lot of statements, such as: Date_add (Utc_timestamp (), INTERVAL 8 HOUR); The SQL statement that displays the time zone: show VARIABLES like System_time_zone and so on. There is no complete solution due to the limitations of MySQL permissions. I Google, found that foreigners this has a very good solution. But he needs to modify the SQ of each inserted dataL statement. Such a scheme is not very effective, once the database time zone is changed to normal, then the corresponding SQL statement should be changed back. And I think since the PHP side has been able to correctly solve the problem of time. MySQL database aspects can be resolved with the corresponding function, but if later migrated to another host environment and change back. and the corresponding field is a TIMESTAMP type, the default value is Currect_timestamp, of course, you can specify the time. So my approach is to let PHP insert the current correct time, so that although the program needs to make corresponding changes. However, the configuration changes in the future as long as you modify one place. Last time you insert a database note the format: date (y-m-d h:i:s) This solves the problem. Attached, some very good references: This will solve the problem. Attached, some very good references: http://www.BkJia.com/html/webkaifa/PHP/PHPyingyong/2010/0226/4000.html update: So wildgoose brother said he also encountered the same problem, but can not solve. After all the assumptions and judgments, it turns out that it was Zend Studio's time zone configuration problem (i kuanghan ing). It appears that in addition to the operating environment, the development environment also needs to be aware of the following.
http://www.bkjia.com/PHPjc/486013.html www.bkjia.com true http://www.bkjia.com/PHPjc/486013.html techarticle due to the temporary use of foreign space, I published a Blog when I found that time is always wrong. This is a time zone problem, based on my previous experience writing programs. This problem is not solved ...
