chrome中js日期对象中奇怪的秒偏移

Question

在年初查看日期对象的 valueOf 值时，我希望总是收到零秒。 以下代码显示，直到 1917 年，chrome 中的偏移量为 54 秒或 40 秒。在 IE 中，我所有年份都收到 0 秒。

这是有原因的吗？它似乎只发生在最后一个 chrome 版本中

   for(var i=0; i<2020;i++)
       if(!new Date(i,0,1).valueOf().toString().match("00000$"))
             console.log({
                    y:i,
                    s: new Date(i,0,1).valueOf().toString().match(/(\d{2})\d{3}$/)[1]})

Answer 1

这不是BUG..

正如@Krzysztof 指出的那样，Chrome 在将Make LocalTZA take 't' and 'isUTC' and drop DSTA(t) 合并到 Ecma 262 之后具有implemented a new spec for timezone offset calculation。所以现在时区转换仅按向后的秒间隔不起作用，它被计算为 what local正在观察特定区域的时间。

说明：

我来自南亚的一个名为孟加拉国的美妙小国，该国遵循BST（孟加拉国标准时间+0600 GMT），即并不总是比格林威治标准时间提前 6 小时。当我在 GMT 打印今年的开始时间时，JavaScript date 采用当地时间，我得到：

new Date(2018, 0, 1).toUTCString()
// "Sun, 31 Dec 2017 18:00:00 GMT"

2009 年，one hour day-light saving 于 6 月 19 日至 12 月 31 日在孟加拉国被观测到。因此，如果我打印 2009 年 12 月的第一天，我会得到：

new Date(2009, 11, 1).toUTCString()
// "Mon, 30 Nov 2009 17:00:00 GMT"

您可以看到夏令时现在反映在日期中，这在我的nodeJS 控制台中不可见。 1941-1942年的当地时间也有变化，如下图，可以在timeanddate.com看到：

所有更改现在都反映在 Chrome 中：

new Date(1941, 6, 1).toUTCString()
// "Mon, 30 Jun 1941 18:06:40 GMT"

new Date(1941, 11, 1).toUTCString()
// "Sun, 30 Nov 1941 17:30:00 GMT"

new Date(1942, 7, 1).toUTCString()
// "Fri, 31 Jul 1942 18:30:00 GMT"

new Date(1942, 11, 1).toUTCString()
// "Mon, 30 Nov 1942 17:30:00 GMT"

所以现在，如果我选择 1941 年之前的任何日期，请记住我的当地时间提前 6 小时，我会看到 6 分 40 秒的偏移量。由于最近 Chrome 的更新，或者特别是 ECMAScript(JavaScript) 的更新，它会根据回溯日期的时区而有所不同。

Answer 2

这可能不是 100% 的问题解决方案，但可以通过将 chrome 转换为 UTC 并返回来获得由 chrome 引入的“抖动”，然后用新的new Date(oldDate.getTime() + jitter) 进行补偿。

        // Compensates for google chrome 67+ issue with very old dates.
        // We should skip this test if any other browser.
        $getJitter: function (d) {
            var utcDate = new Date(Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate(), d.getUTCHours(), d.getUTCMinutes(), d.getUTCMilliseconds())),
                jitter = 0;

            // As we're setting UTC date, the non-UTC year could be
            // shifted one ahead or behind, so set the utc full
            // year to ensure compliance.
            utcDate.setUTCFullYear(d.getUTCFullYear());

            if (d.getFullYear() != utcDate.getFullYear() ||
                d.getMonth() != utcDate.getMonth() ||
                d.getDate() != utcDate.getDate() ||
                d.getHours() != utcDate.getHours() ||
                d.getMinutes() != utcDate.getMinutes() ||
                d.getMilliseconds() != utcDate.getMilliseconds()) {

                // infers the "jitter" introduced during the conversion to compensate in the
                // actual value of ticks
                jitter = d.getTime() - utcDate.getTime()
            }

            return jitter;
        }

这种“抖动”很大程度上取决于时区。对于巴西，我收到了 28 秒的噪音（所以它会恢复到前一天的 12:00:00 AM > 23:59:32 PM。

对于巴西，问题发生在 1913 年。这与我们将夏令时和时区从 -3:06 变为 -3:00 的时间一致，根据https://www.timeanddate.com/time/zone/brazil/sao-paulo 多年来的时间变化。

使用上面的代码，您可以使用此循环探索损坏的日期：

for (var i=1900; i < 2020; i++) {
 for (var j=0; j < 12; j++) {
  var dt = new Date(i, j, 1);
  var jitter = System.DateTime.$getJitter(dt);
  if (jitter != 0) {
   console.log("broken: " + i + ", " + j + ", jitter: " + (jitter/1000) + "s: " + dt.toString());
  }
 }
}