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到凌晨2点完全跳过凌晨3点.问题是我们有多个日期时间选择器没有这个概念(这没关系)所以你仍然可以选择2am次.我希望当我从早上2点开始构建一个日期时,它会被推到凌晨3点,所以2:05变为3:05.Chrome处理这个很好,但Firefox似乎将它推回到1:05.UTC关闭了一个小时,但是当您使用时区格式化时,它将显示为1:05.

我该如何解决这个问题？我认为答案只是"momentjs",但我想理解为什么这是不同的.

Answer 1

你是对的.Spring Forward DST过渡将产生无效的当地时间差距.JavaScript会向前推进它,也就是差距.在ECMAScript规范中没有定义它的方向,因此不同的浏览器以不同的方式进行.恕我直言,前进是最符合逻辑的(从时间向前),但有些人认为应该优先使用"标准"时间.

对于Fallback DST转换,存在一段重叠的本地时间,其中本地时间可能不明确.JavaScript将其映射到第一个实例(白天时间)或第二个实例(标准时间).再如,有的觉得"标准"的时间应者优先,但它使更多的逻辑意义在那个时候实际发生的顺序去-这意味着选择日光实例.

以下是横向当前查找桌面浏览器的方式:

在过去的几年里,我已经多次更新了这些图表,因为它甚至在浏览器中也在版本之间进行了更改.我为Pluralsight课程制作的第一个版本看起来很不一样.许多浏览器已从行为的一方翻转到另一方.所以要小心做出任何假设 - 旧浏览器很可能与此图表存在差异.我也没有展示大量的移动网络浏览器.

现在你问了如何处理这个问题.不幸的是,没有很多好的选择.你提到moment.js,这的确是日期和时间的一个伟大的图书馆-但因为它目前依赖于在Date引擎盖下的对象,它并没有解决这方面的问题.它继承了浏览器的任何行为.(这是一个已知问题,我们正在研究它.)

更新

我之前写过一些函数来展示如何解决这个问题.如果您查看编辑历史记录,仍可以找到这些内容.不幸的是,我用isShiftedForward和isShiftedBackward方法犯了一个严重的错误.虽然true如果时间戳已经移位,它们会返回,但是当给出与转换紧邻的有效时间戳时,它们也返回true(错误).(也就是说,在向前移动的后一小时,或在向后移动之前的小时.)

因此,我从答案中删除了这些功能.如果不知道创建Date对象的原始值,就无法避免这种情况.他们无法Date单独从对象中工作.