我运行以下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在这里执行夏令时操作的建议，以及一些关于为什么所有结果都相同的解释。
MySQL的行为是正确的，如果你的服务器的时区"CDT"遵守DST，并且你没有将会话时区设置为不同的时区。
UNIX_TIMESTAMP()函数使用会话的时区来插入您为其提供的值。
服务器将日期解释为当前时区中的值，并将其转换为 UTC 格式的内部值。
。
注： 如果使用
UNIX_TIMESTAMP()和FROM_UNIXTIME()在TIMESTAMP值和 Unix 时间戳值之间进行转换，则转换是有损的，因为映射不是双向一对一的。例如，由于本地时区更改的约定，两个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。 此语句仅设置会话的时区，而不设置整个服务器。
如果运行SET @@TIME_ZONE = 'UTC';会给您带来错误消息，例如 ERROR 1298 (HY000): Unknown or incorrect time zone: 'UTC' ，则可能是您没有使用时区信息填充 MySQL。如此处所述，您可以使用以下命令加载此信息：
mysql_tzinfo_to_sql /usr/share/zoneinfo/ | mysql -u root mysql -p
其中路径/usr/share/zoneinfo可能需要替换为特定于系统的路径。