Chrome 和 Firefox 对“无效”DST 时间的处理方式不同

Question

最小的例子：

var test = new Date();
test.setMonth(3);
test.setDate(3);
test.setHours(2);
test.getUTCHours()`

在 Firefox 上我得到“7”，Chrome 给我“8”（我认为正确答案）。

DST 即将到来，我的任务是解决我们的 javascript 更改带来的各种问题。我不确定如何处理这个问题。时间向前移动了 1 小时，所以我们将从 1:59:59 到 3:00:00 完全跳过凌晨 2 点。问题是我们有多个没有这个概念的日期时间选择器（没关系），所以你仍然可以选择凌晨 2 点的时间。我希望当我从凌晨 2 点构建一个日期时，它会被推到凌晨 3 点，所以 2:05 变为 3:05。 Chrome 处理得很好，但 Firefox 似乎将其推回到 1:05。 UTC 相差一小时，但是当您使用时区进行格式化时，它将显示为 1:05。

我该如何解决这个问题？我认为答案只是“momentjs”，但我想了解为什么会有所不同。

Answer 1

你是对的。 Spring Forward DST 转换将创建一个无效本地时间的间隙。 JavaScript 要么将其向前推进，要么向后推进，幅度为差距。 ECMAScript 规范中没有定义它的方向，因此不同的浏览器会以不同的方式执行。恕我直言，向前移动最符合逻辑（因为时间向前移动），但有些人认为应该首选使用“标准”时间。

对于回退 DST 过渡，有一段重叠的本地时间，其中本地时间可能不明确。 JavaScript 会将其映射到第一个实例（夏令时）或第二个实例（标准时间）。同样，有些人认为应该首选“标准”时间，但按照实际发生的时间顺序进行更合乎逻辑 - 这意味着选择 daylight 实例。

以下是桌面浏览器当前的风景：

在过去的几年里，我已经多次更新这些图表，因为即使在浏览器中，它也在版本之间发生了变化。我为my Pluralsight course 制作的第一个版本看起来完全不同。许多浏览器已经从行为的一侧转向另一侧。所以做任何假设都要小心——旧的浏览器很可能与这个图表有很大的不同。我也没有展示大量的移动网络浏览器。

现在你问如何处理这个问题。不幸的是，没有很多好的选择。您提到了 moment.js，它确实是一个很棒的日期和时间库——但由于它目前依赖于底层的 Date 对象，它并不能解决这个特殊问题。它继承了浏览器的任何行为。 （这是一个已知问题，我们正在努力解决。）

更新

我之前写过一些函数来展示如何解决这个问题。如果您查看编辑历史记录，您仍然可以找到这些。不幸的是，我在isShiftedForward 和isShiftedBackward 方法上犯了一个严重错误。尽管如果时间戳已被移动，它们会返回 true，但当给定紧邻转换的有效时间戳时，它们也会返回 true（错误地）。 （即向前移动时在下一小时内，或向后移动时在前一小时内。）

因此，我已从答案中删除了这些功能。如果不知道创建 Date 对象的原始值，就无法避免这种情况。它们无法单独使用 Date 对象。