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

当我在一年前查看date对象的value时，我希望总是得到零秒。 下面的代码显示，直到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]})

---

for（var i=0；i这可能不是问题的100%解决方案，但可以通过将chrome引入的“抖动”转换到UTC并返回，然后使用新的
新日期（oldDate.getTime（）+抖动）进行补偿。

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

对巴西来说，这个问题发生在1913年。根据几年来的时间变化，这与我们将夏令时和时区从-3:06调整到-3:00的时间一致

使用上述代码，您可以使用此循环探索中断日期：

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());
  }
 }
}

for（变量i=1900；i<2020；i++）{
对于（var j=0；j<12；j++）{
var dt=新日期（i，j，1）；
var jitter=系统日期时间$getJitter（dt）；
如果（抖动！=0）{
log（“断开：“+i+”，“+j+”，抖动：”+（抖动/1000）+“s:+dt.toString（））；
}
}
}

这不是一个BUG

正如@Krzysztof所指出的，Chrome在合并到Ecma 262之后已经停止了工作。因此，现在时区转换不能仅以秒的向后间隔工作，它是根据在特定区域中观察到的本地时间来计算的

说明：

我来自一个奇妙的小国，名为孟加拉国，隶属于南亚，紧随英国夏令时（孟加拉国标准时间+0600 GMT），并不总是比GMT早6个小时。当我用GMT打印今年的开始时间时，JavaScript
date
采用当地时间，我得到：

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

2009年6月19日至12月31日在孟加拉国观察到。因此，如果我打印2009年12月的第一天，我会得到：

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

您可以看到日光节约现在反映在date now中，而date now在my
nodeJS
控制台中不可见。1941-1942年的本地时间也发生了变化，如下所示，可以在上看到：


所有这些变化现在都反映在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）的更新而有所不同。
换句话说：
新日期（1915，0，1，0，0，0）。ToutString（）
会导致
“Thu，Dec 1914 22:36:00 GMT”（/code>）（Chrome 67.0.3396.87）。这真的很奇怪，我认为这是一个bug。你报告了吗？在Chrome 67.0.3396.87中，在Windows
新日期（1915，0，1，0，0，0，0，0，0）上。ToutString（）返回
“Fri，Jan 1915 00:00 GMT”
@KrzysztofGrzybek作为旁注：
新日期（1915,0,1,0,0,0）
给出输出“1915年1月1日星期五00:00:00 GMT+0124”，差值实际上是1小时24分钟。另外
getTimezoneOffset
返回-84（1小时24分钟）这是Chrome 67引入的一个恼人的错误。它似乎想使用历史数据中的某种插值时区（你可以在中看到1800年以前的历史时区），这是在日期中添加这些分钟的变化。大家：这不是一个错误。几乎每个时区都会发生这种情况，并且tz数据库中的值已经存在了近三十年。如果您的代码无法处理1883–1914年之前的值，那么我保证您的代码在夏令时转换期间也是不正确的我只想补充一点，这不是chrome中的一个bug，这种行为最近在ecma规范中定义过，所以它可能很快也会出现在其他浏览器中。我仍然相信那里有一个bug，好像我转换为UTC，然后回到时间，我得到了一个不同的值。我t至少应该是一致的。你不是“转换到UTC然后再回到时间”。您正在丢弃UTC偏移量，丢弃秒字段，然后抱怨值不同。将UTC偏移量从一个日期应用到另一个日期是完全错误的。我正在获取时间是否有秒抖动，以便可以删除它，这是为了克服恼人的问题。我故意将数据删除到看看它是否会改变不需要的字段，这样我才能识别和克服问题，而且只有当问题发生时……你的意思是chrome在全世界都发生了变化。这不是夸大了吗？chrome在耶路撒冷有变化（+02:00）回到公元0018年。我不能同意这也不是一个bug。这带来了比没有更多的麻烦。至少应该有一种方法可以避免这种只出现在chrome上的细致的时区考虑。这只是回到浏览器战争。@Fabriciomurta这不是一个bug，而是JavaScript的更新，迟早会发生ter所有浏览器都将实现它。绕过它的最简单方法是使用
Date.UTC
。而不是
新日期（1942,11,1）
使用
新日期（Date.UTC（1942,11,1））
。
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"