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

我已经为我的目的弄清楚了。我将总结一下我学到的东西(对不起，这些说明很冗长；它们对我将来的推荐一样重要。)

相反的是我在我以前的意见一说，DATETIME和TIMESTAMP领域也表现不同。TIMESTAMP字段(如文档所示)采用您以“ YYYY-MM-DD hh：mm：ss”格式发送的内容，并将其从当前时区转换为UTC时间。每当您检索数据时，透明地进行相反操作。DATETIME字段不进行此转换。他们接受您发送给他们的任何东西，然后直接存储。

DATETIME和TIMESTAMP字段类型都不能在遵守DST的时区中准确存储数据。如果您存储“ 2009-11-01 01:30:00”，则这些字段将无法区分所需的1:30 am版本--04：00或-05：00版本。

好的，因此我们必须将数据存储在非DST时区(例如UTC)中。出于以下原因，TIMESTAMP字段无法正确处理此数据：如果您的系统设置为DST时区，那么您放入TIMESTAMP中的内容可能就不会回来。即使您将已经转换为UTC的数据发送给它，它仍将假定该数据位于您当地的时区，并再次转换为UTC。当您的本地时区遵守DST时，此TIMESTAMP强制的从本地到UTC到本地到本地的往返行程是有损的(因为“ 2009-11-01 01:30:00”映射到2个不同的可能时间)。

使用DATETIME，您可以将数据存储在所需的任何时区中，并有信心将获得任何发送的数据(不会强迫您将TIMESTAMP字段强制执行的有损往返转换)。因此，解决方案是使用DATETIME字段，然后将其保存到该字段之前，将其从系统时区转换为要保存在其中的任何非DST时区(我认为UTC可能是最佳选择)。这使您可以将转换逻辑构建到脚本语言中，以便可以显式保存与“ 2009-11-01 01:30:00 -04：00”或“ 2009-11-01 01:30”等价的UTC： 00 -05：00”。

另一个需要注意的重要事项是，如果将日期存储在DST TZ中，则MySQL的日期/时间数学函数无法在DST边界附近正常工作。因此，更需要保存UTC的原因。

简而言之，我现在这样做：

从数据库检索数据时：

明确将数据库中的数据解释为MySQL之外的UTC，以获取准确的Unix时间戳。我为此使用PHP的strtotime()函数或其DateTime类。无法使用MySQL的CONVERT_TZ()或UNIX_TIMESTAMP()函数在MySQL内部可靠地完成此操作，因为CONVERT_TZ仅会输出“ YYYY-MM-DD hh：mm：ss”值，该值存在歧义性问题，并且UNIX_TIMESTAMP()假定其值为输入的时间是系统时区，而不是数据实际存储在(UTC)中的时区。

将数据存储到数据库时：

将您的日期转换为您希望在MySQL以外的确切UTC时间。例如：使用PHP的DateTime类，可以与“ 2009-11-01 1:30:00 EDT”不同地指定“ 2009-11-01 1:30:00 EST”，然后将其转换为UTC并保存正确的UTC时间到您的DATETIME字段。

ew 非常感谢大家的投入和帮助。希望这可以节省其他人的麻烦。

顺便说一句，我在MySQL 5.0.22和5.0.27上看到了这一点