Javascript 日期构造函数的不同行为

我在js中使用新日期（stringFormat）时有奇怪的行为

为什么会产生这样的结果：

 var date = new Date('2020-03-01') 
 console.log(date.toISOString())

不同于

 var date = new Date(2020,2,1) 
 console.log(date.toISOString())

这就是我得到的

2020-03-01T00:00:00.000Z
2020-02-29T23:00:00.000Z

我想永远拥有第一个结果。 我想了解为什么这两者之间有区别，我知道这是时区的问题，但我在两种情况下提供相同的日期，但结果不同。这些重载是否过时了

两种方法对时区的解释不同的原因是什么？ 我是否可以假设在每个时区和每个浏览器中，从第一个方法我将得到第一个结果

来自：

使用

date

构造函数解析日期字符串（和

Date.parse（）
浏览差异和不一致

具体到你的问题（我的重点）：

对ISO 8601格式的支持不同于仅日期字符串（例如。
“1970-01-01”
）被视为UTC，而非本地

这就解释了你所看到的时区处理的不同

比较以下两条语句的输出：


console.log（新日期（'2020-03-01'）.toISOString（））；
console.log（新日期（'2020-03-01T00:00:00'）.toISOString（））ISO字符串被认为是UTC，另一个被认为是本地的。我知道，但是你可以看到我在这两个字符串上都调用了toISOString，结果是不同的，这可能是因为你的时区不是UTC。第一个是
2020-03-01T00:00:00+00:00
，第二个是
2020-03-01T00:00:00+01:00
，因为您的本地时区很可能是英国。如果不是的话，你就知道它仍然是+1时区。因此，当您将后者转换为UTC日期时，它是一个小时后的时间，这也将日期向后移动。我不是问UTC和本地时间之间的差异，我是问新日期（stringFormat）与新日期（年、月、日）之间的差异，我再次解释了这一点-第一个被视为UTC，第二个是本地。你说你理解这一点，但仍然问为什么输出不同。那么，问题是什么？两个不同的时间戳是不同的。如果它们指向相同的日期时间，但它们位于不同的时区，这也会使它们具有不同的时间戳。好的，这是否意味着我可以始终假定它将被视为UTC，而不是本地？或者它可能在不同的浏览器中有所不同，或者可能在未来的ECMA版本中有所改变？@strengat为了确保这一点，请始终在时间戳中包含
Z
。在使用
date
构造函数解析日期字符串时，我认为最好不要做太多假设。我希望在即将发布的ECMAScript版本中，我们会看到一个新的日期/时间API。我还希望这将有效地冻结当前
Date
类的行为。