我正在使用美国/纽约时区。在秋天，我们“退回”一小时 - 在凌晨2点有效地“获得”一小时。在转换点，会发生以下情况：
现在是01:59:00 -04：00 然后1分钟后变成： 01:00:00 -05：00
因此，如果您只是简单地说“凌晨1点30分”，那么您是指第一次1:30滚动还是第二次推测是不明确的。我正在尝试将调度数据保存到MySQL数据库，无法确定如何正确保存时间。
这是问题所在： “2009-11-01 00:30:00”在内部存储为2009-11-01 00:30:00 -04：00 “2009-11-01 01:30:00”在内部存储为2009-11-01 01:30:00 -05：00
这很好，也很合理。但是如何保存到01:30:00 -04：00呢？ documentation没有显示任何支持指定偏移量，因此，当我尝试指定偏移量时，它已被正确忽略。
我想到的唯一解决方案是将服务器设置为不使用夏令时的时区，并在我的脚本中进行必要的转换（我正在使用PHP）。但这似乎不应该是必要的。
非常感谢任何建议。
坦率地说，MySQL的日期类型已被破坏，并且无法正确存储所有时间，除非您的系统设置为常量偏移时区，如UTC或GMT-5。 （我使用的是MySQL 5.0.45）
这是因为您无法在夏令时结束前的一小时内存储任何时间。无论您如何输入日期，每个日期函数都会将这些时间视为切换后的一小时内。
我的系统的时区是America/New_York。让我们试试存储1257051600（Sun，2009年11月1日06:00:00 +0100）。
这里使用专有的INTERVAL语法：
SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3599 SECOND); # 1257051599
SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3600 SECOND); # 1257055200
SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 1 SECOND); # 1257051599
SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 0 SECOND); # 1257055200
甚至FROM_UNIXTIME()也不会返回准确的时间。
SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(1257051599)); # 1257051599
SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(1257051600)); # 1257055200
奇怪的是，DATETIME仍将在DST开始的“丢失”时间内存储并返回（仅以字符串形式！）次数（例如2009-03-08 02:59:59）。但是在任何MySQL函数中使用这些日期都是有风险的：
SELECT UNIX_TIMESTAMP('2009-03-08 01:59:59'); # 1236495599
SELECT UNIX_TIMESTAMP('2009-03-08 02:00:00'); # 1236495600
# ...
SELECT UNIX_TIMESTAMP('2009-03-08 02:59:59'); # 1236495600
SELECT UNIX_TIMESTAMP('2009-03-08 03:00:00'); # 1236495600
要点：如果你需要在一年中的每一次存储和检索，你有一些不受欢迎的选择：
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。
我已经弄清楚了我的目的。我会总结一下我学到的东西（对不起，这些笔记很冗长;它们和我未来的推荐一样多）。
与我在之前的评论中所说的相反，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（因为“2009-11-01 01:30:00”映射到2个不同的可能时间）时，这个TIMESTAMP强制执行的本地到UTC回到本地的往返是有损的。
使用DATETIME，您可以将数据存储在您想要的任何时区，并确信您将收到任何您发送的数据（您不会被迫进入TIMESTAMP字段强加给您的有损往返转换）。所以解决方案是使用DATETIME字段并在保存到字段之前将系统时区转换为您要保存的任何非DST区域（我认为UTC可能是最佳选择）。这允许您将转换逻辑构建到脚本语言中，以便您可以显式保存UTC等效于“2009-11-01 01:30:00 -04：00”或“”2009-11-01 01:30： 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字段。
唷。非常感谢大家的投入和帮助。希望这可以为其他人带来一些令人头疼的问题。
顺便说一下，我在MySQL 5.0.22和5.0.27上看到了这一点
我认为micahwittman的link具有解决这些MySQL限制的最佳实用解决方案：连接时将会话时区设置为UTC：
SET SESSION time_zone = '+0:00'
然后你只需发送它的Unix时间戳，一切都应该没问题。
这个线程让我变得怪异，因为我们使用TIMESTAMP列与On UPDATE CURRENT_TIMESTAMP（即：recordTimestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP）来跟踪已更改的记录和ETL到数据仓库。
如果有人想知道，在这种情况下，TIMESTAMP行为正确，你可以通过将TIMESTAMP转换为unix时间戳来区分两个相似的日期：
select TestFact.*, UNIX_TIMESTAMP(recordTimestamp) from TestFact;
id recordTimestamp UNIX_TIMESTAMP(recordTimestamp)
1 2012-11-04 01:00:10.0 1352005210
2 2012-11-04 01:00:10.0 1352008810
但是如何保存到01:30:00 -04：00呢？
你可以转换为UTC，如：
SELECT CONVERT_TZ('2009-11-29 01:30:00','-04:00','+00:00');
您可以使用qazxsw poi从UTC转换为当地时间：
CONVERT_TZ
其中'+00：00'是UTC，来自时区，'SYSTEM'是运行MySQL的操作系统的本地时区。
Mysql固有地使用mysql db中的time_zone_name表解决了这个问题。在CRUD时使用CONVERT_TZ更新日期时间而不必担心夏令时。
SELECT CONVERT_TZ(UTC_TIMESTAMP(),'+00:00','SYSTEM');
我正在研究记录页面访问次数和在图表中显示计数（使用Flot jQuery插件）。我在表格中填写了测试数据，一切看起来都很好，但我注意到在图表的末尾，根据x轴上的标签，这些点是一天休息。经过检查，我注意到2015-10-25天的视图计数从数据库中检索了两次并传递给Flot，因此在此日期之后的每一天都被移动了一天到右边。 在我的代码中查找了一段时间的错误后，我意识到这个日期是DST发生的时间。然后我来到这个SO页面...... ...但建议的解决方案对我需要的东西来说太过分了，或者他们有其他缺点。我不是很担心无法区分模糊的时间戳。我只需要计算并显示每天的记录。
首先，我检索日期范围：
SELECT
CONVERT_TZ('2019-04-01 00:00:00','Europe/London','UTC') AS time1,
CONVERT_TZ('2019-03-01 00:00:00','Europe/London','UTC') AS time2;
然后，在一个for循环中，从SELECT
DATE(MIN(created_timestamp)) AS min_date,
DATE(MAX(created_timestamp)) AS max_date
FROM page_display_log
WHERE item_id = :item_id
开始，以min_date结束，一天的步骤（max_date），我正在检索计数：
60*60*24我对问题的最终和快速解决方案是：
for( $day = $min_date_timestamp; $day <= $max_date_timestamp; $day += 60 * 60 * 24 ) {
$query = "
SELECT COUNT(*) AS count_per_day
FROM page_display_log
WHERE
item_id = :item_id AND
(
created_timestamp BETWEEN
'" . date( "Y-m-d 00:00:00", $day ) . "' AND
'" . date( "Y-m-d 23:59:59", $day ) . "'
)
";
//execute query and do stuff with the result
}
所以我不是在一天开始时盯着循环，而是两小时后。这一天仍然是相同的，我仍在检索正确的计数，因为我明确要求数据库在当天的00:00:00和23:59:59之间记录，而不管时间戳的实际时间。当时间跳了一个小时，我仍然在正确的一天。
注意：我知道这是一个5岁的线程，我知道这不是OP问题的答案，但它可能会帮助像我这样的人找到解决我描述的问题的方法。