来源: 互联网  发布时间: 2013-11-30

However, there are ways for you to get results that are in your preferred timezone. First determine how many hours your desired timezone is off from MST. For example, EST is +2 hours. PST is -1 hour.

Knowing the time offset, you can replace all your SQL statements of 


SELECT NOW();

with


SELECT DATE_ADD(NOW(), INTERVAL 2 HOUR);

which will give you an EST date result. For a result in PST, you would do:


SELECT DATE_SUB(NOW(), INTERVAL 1 HOUR);

If you are working with time in seconds instead of dates, then factor in the offset in seconds. Because there are 3600 seconds in an hour, and EST is 2 hours later than MST, the following converts timestamps from MST to EST:


SELECT unix_timestamp() + (3600 * 2);

SELECT FROM_UNIXTIME(UNIX_TIMESTAMP() + (3600 * 2));

See the MySQL Manual's Date and Time Functions for more information.

Depending on your application, you may also need to do one of the following (but not both):

1. Find every place in your code where a date or time is displayed to the browser and have a user defined function change it to add or subtract the appropriate number of hours before displaying it.

2. Find every place in your code where dates or times are input into your system and have a user defined function add or subtract the appropriate number of hours before storing it.

    

    来源: 互联网  发布时间: 2013-11-30

PHP 脚本端的市区设置可以在 php.ini 下设置 date.timezone 键的值为 'Asia/Shanghai' 即可。但是通常共享虚拟主机本身没有修改 php.ini 权限。这个时候就应该在程序公共部分加入

ini_set('date.timezone','Asia/Shanghai');动态修改 php.ini 的设置。之后可以测试一下时间是否正确：

var_dump(date());如果服务器的本地时间是正确的，那么一般就能解决问题了。附，PHP 5.1 以上提供了专门的函数修改对应的时区：

date_default_timezone_set('Asia/Shanghai');建议使用此函数，因为更通用一些。对应 'Asia/Shanghai' 其他可以使用的大陆时区还有：Asia/Chongqing 、Asia/Shanghai 、Asia/Urumqi （依次为重庆，上海，乌鲁木齐）；港台地区可用：Asia/Macao、Asia/Hong_Kong、Asia/Taipei（依次为澳门，香港，台北）；还有新加坡：Asia/Singapore；其他可用的值是：Etc/GMT-8、Singapore、Hongkong、PRC；老外好像把北京漏调了。

但是，在我修改成功 PHP 端的时区以后发现日期并没有正确的记录下来。这个时候我考虑是否是数据库的问题。果不其然，因为程序插入的函数并没有调用 PHP 的时间，而是直接使用 MySQL 的 CURRECT_TIMESTAMP。这个时候就要考虑是否能修改 MySQL 方面的时区。

参考了 MySQL 的文档，发现一个可行的 SQL 语句为：

SET GLOBAL time_zone = '+8:00'; 其中 '+8:00' 是东八区的表示方法，其他的市区依次类推。而我在数据库模型中插入改语句发现权限不够（该死的虚拟主机提供商）。接下来我调试了很多语句，比如：

DATE_ADD(UTC_TIMESTAMP(), INTERVAL 8 HOUR);显示时区的 SQL 语句：

SHOW VARIABLES LIKE 'system_time_zone'等等。而由于 MySQL 权限的限制并没有彻底的解决方案。我 Google 了下，发现老外这个有一个非常好的解决方案。但是他需要修改每条插入数据的 SQL 语句。这样的方案并不是非常的有效，一旦数据库时区改成正常，那么相应的 SQL 语句又要改回来。

而我考虑既然 PHP 端已经可以正确的解决时间的问题了。MySQL 数据库方面虽然可以使用相应的函数解决，但是如果日后迁移到别的主机环境又要改回来。而相应的字段是一个 TIMESTAMP 类型的，默认的值为 CURRECT_TIMESTAMP，当然是可以指定时间的。

那么我的做法就是让 PHP 插入当前正确的时间，这样虽然程序方面需要做相应的修改。不过日后配置修改起来只要修改一处就可以了。最后插入数据库的时间注意一下格式：

date('Y-m-d H:i:s')这样就可以解决问题了。附，一些非常好的参考资料：

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 
更新：由此 wiLdGoose 兄说他也碰到同样的问题，但是无法解决。结果经过种种的假设和判断以后，到最后发现原来是 Zend Studio 的时区配置问题（我狂汗ing）。看来除去运行环境，开发环境也是需要注意以下的。
今天我也遇到这个问题了,我比你幸运,自己的主机,可以:
SET GLOBAL time_zone = '+8:00'; 
呵呵,你可惜了,不能用 UNIX_TIMESTAMP() 这样的函数了.

    

    来源: 互联网  发布时间: 2013-11-30

 由于曾经和他是同一个团队的，所以对于其我很熟悉他那“洁癖”的做法，对于他的很多的观点我也非常的赞同；但是有一件非常不理解的地方就是设计数据库的时候总是会回避使用 Date/Time 类型。他的做法是将时间相关的字段设置为 INT(10) 类型，然后用 UNIX 时间戳来存储。而我本人对于这点做法非常的不赞同：

首先，是类型操作的不同，类似于 wiLdGoose 这样做法的“时间计算”实质上是整形之间的操作（而且这个整形非常大，长度为 10）。更有甚者，将时间戳设置为 VARCHAR(10) ，由此引发的效率问题不言而喻。

至于时间计算和整形计算乃至字符串的计算的效率问题，这篇文章非常能说明问题。

其次，是逻辑方面的操作问题。这是使用时间类型的优势，尤其是在需要高精度的项目上。比如需要“前一个星期的数据”和“获得从数据库建立以来每个星期一的数据”，这样的操作如用 wiLdGoose 兄的做法复杂度可想而知。

最后，就是直观不直观的问题，可以理解的是我们的大脑是不会直接将这一大串的时间戳转换成日期格式的。相比而言，直接使用时间类型明显就直观得多（它本身就是时间格式）。

而我目前的团队也还是在使用类似的方法。本人对于类似技术细节也争执了良久，但由于岗位和决定权的问题，团队还是无法采纳本人的意见，甚为遗憾。

MySQL 定位为简单快速的 DBM 自然能迅速的驾驭，但是另一方面很容易造成不会深入下去的局面。对于此，我们更应该注意每一项的数据库设计细节，一项产品不断添加新的功能到最后都是面向应用的。

最后，附 MySQL 官方的时间和日期函数的手册。