3

我运行以下 MySQL 查询：

select unix_timestamp('2011-03-13 02:00:13'), unix_timestamp('2011-03-13 02:20:41'), unix_timestamp('2011-03-13 02:40:10');

并得到以下奇怪的结果：

1300003200, 1300003200, 1300003200

我认为这里有某种夏令时，尽管所有值都神奇地相同似乎仍然很奇怪。

我很感激有关如何防止 MySQL 在这里执行夏令时的建议，以及对为什么所有结果都相同的一些解释。

4

1 回答 1

2

MySQL 的行为是正确的，如果您的服务器的时区“CDT”遵守 DST 并且您没有将会话时区设置为不同的值。

该UNIX_TIMESTAMP()函数使用您会话的时区来解释您给它的值。

服务器将日期解释为当前时区的值，并将其转换为 UTC 的内部值。

...

注意：如果使用UNIX_TIMESTAMP()and在值和 Unix 时间戳值FROM_UNIXTIME()之间进行转换TIMESTAMP，则转换是有损的，因为映射在两个方向上不是一对一的。例如，由于本地时区更改的约定，两个UNIX_TIMESTAMP()人可以将两个TIMESTAMP值映射到相同的 Unix 时间戳值。FROM_UNIXTIME()将该值映射回仅一个原始TIMESTAMP值。

— http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_unix-timestamp

有问题的时间戳在您的时区中不存在，因此服务器会为您提供最准确的答案......这是时钟向前移动的 UTC 时间，当时间向前移动时，不到一小时前您的日期时间文字，代表您所在时区中的“那天从未存在过的时间”。

如果这些时间戳是您当地时区的时间，那么答案是那些是无效值，因为那个时间从未发生在您所在的地方。另一方面，如果实际上假定这些时间戳已经采用 UTC，那么您将无法从UNIX_TIMESTAMP()任何查询中获得正确答案，因为时间是“从”时区转换而来的，它实际上并未以.

如果您SET @@TIME_ZONE = 'UTC';重复查询，您会明白我的意思，因为 UTC 没有 DST。此语句仅设置会话的时区，而不是整个服务器。

如果 runningSET @@TIME_ZONE = 'UTC';给你一个错误消息，例如ERROR 1298 (HY000): Unknown or incorrect time zone: 'UTC'，很可能你没有用 timezone 信息填充 MySQL。如此处所述，您可以使用以下命令加载此信息：

mysql_tzinfo_to_sql /usr/share/zoneinfo/ | mysql -u root mysql -p

其中路径/usr/share/zoneinfo可能需要替换为特定于您的系统的路径。

于 2013-10-16T03:07:11.987 回答