MySQL日期时间字段和夏时制-如何引用“额外”小时？

MySQL日期时间字段和夏时制-如何引用“额外”小时？

坦率地说，MySQL的日期类型已损坏，无法正确存储 所有 时间，除非将系统设置为恒定的偏移时区，例如UTC或GMT-5。（我正在使用MySQL
5.0.45）

这是因为 您无法在夏令时结束前的一个小时内存储任何时间 。无论您如何输入日期，每个日期函数都会将这些时间视为在切换后的一小时内。

我的系统的时区为

America/New_York

。让我们尝试存储1257051600（星期日，2009年11月1日06:00:00 +0100）。

这里使用专有的INTERVAL语法：

SELECt UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3599 SECOND); # 1257051599SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3600 SECOND); # 1257055200SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 1 SECOND); # 1257051599SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 0 SECOND); # 1257055200

甚至

FROM_UNIXTIME()

不会返回准确的时间。

SELECt UNIX_TIMESTAMP(FROM_UNIXTIME(1257051599)); # 1257051599SELECt UNIX_TIMESTAMP(FROM_UNIXTIME(1257051600)); # 1257055200

奇怪的是，DSTTIME 仍将 在DST开始的“丢失”时间内存储和返回（仅以字符串形式！）时间（例如

2009-03-0802:59:59

）。但是在任何MySQL函数中使用这些日期都是有风险的：

SELECT UNIX_TIMESTAMP('2009-03-08 01:59:59'); # 1236495599SELECT UNIX_TIMESTAMP('2009-03-08 02:00:00'); # 1236495600# ...SELECT UNIX_TIMESTAMP('2009-03-08 02:59:59'); # 1236495600SELECT UNIX_TIMESTAMP('2009-03-08 03:00:00'); # 1236495600

要点：如果您需要在一年中的 每个 时间进行存储和检索，则有一些不受欢迎的选择：

1. 将系统时区设置为GMT +一些恒定的偏移量。例如UTC

2. 将日期存储为INT（如Aaron发现的，TIMESTAMP甚至不可靠）

3. 假设DATETIME类型具有一些恒定的偏移时区。例如，如果您在使用

   America/New_York

   ，请将日期转换 为MySQL之外的 GMT-5 ，然后将其存储为DATETIME（事实证明这很重要：请参阅Aaron的回答）。然后，您必须格外小心地使用MySQL的日期/时间函数，因为某些函数假设您的值是系统时区，而其他函数（尤其是时间算术函数）则是“时区不可知的”（它们的行为就像是UTC）。

Aaron和我怀疑自动生成的TIMESTAMP列也已损坏。两者

2009-11-01 01:30 -0400

和

2009-11-01 01:30-0500

将被存储为模棱两可

2009-11-01 01:30

。