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

时间:2018-06-14 12:07:02

标签: javascript google-chrome datetime

当在一年的开始时查看日期对象的valueOf值时,我预计总是会收到零秒。 以下代码显示,直到1917年,chrome中的偏移量为54秒或40秒。在IE中我所有年份都收到0秒。

这有什么理由吗?它似乎只发生在最后一个chrome版本

M6

2 个答案:

答案 0 :(得分:12)

  

这是不是错误。.

@Krzysztof指出,在implemented a new spec for timezone offset calculation合并到Ecma 262之后,Chrome浏览器有了Make LocalTZA take 't' and 'isUTC' and drop DSTA(t)。因此,时区转换仅在倒数秒间隔内不起作用,其计算方式为< em>在特定区域观察到的当地时间。

  

说明:

我来自南亚的一个叫做孟加拉的奇妙小国,紧随 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上看到:

enter image description here

所有更改现在都反映在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)的更新,它会根据截止日期的时区而有所不同。

答案 1 :(得分:5)

这可能不是100%解决问题的方法,但是可以通过将铬投射到UTC并返回,然后用新的if(request.getAttribute("messageResponse")!=null){ out.println(request.getAttribute("messageResponse")); } 进行补偿,来获得chrome引入的“抖动”。

new Date(oldDate.getTime() + jitter)

此“抖动”在很大程度上取决于时区。对于巴西,我听到28秒的声音(所以回到前一天的12:00:00 AM> 23:59:32 PM。

对于巴西来说,该问题一直持续到1913年。这与根据https://www.timeanddate.com/time/zone/brazil/sao-paulo多年来的时间变化,我们将夏令时和时区从-3:06更改为-3:00的时间一致。

使用上面的代码,您可以通过以下循环探索残破的日期:

        // 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;
        }