为什么JavaScript将1/1/0000解释为1/1/2000？

我遇到了一些奇怪的行为，虽然我真的没有问题，但我想知道背后的原因

我写了以下声明：

console.log(new Date("0000-1-1"));
console.log(new Date("0000-01-01"));
console.log(new Date("0000-01-01T00:00:00Z"));
console.log(new Date(0, 0, 1));

虽然所有日期“看起来”都是相似的，如果您使用的是正常的日/月/年，则其行为相同，但在本例中并非如此

结果如下：

Sat Jan 01 2000 00:00:00 GMT+0100 (CET)
Sat Jan 01 0 01:00:00 GMT+0100 (CET)
Sat Jan 01 0 01:00:00 GMT+0100 (CET)
Mon Jan 01 1900 00:00:00 GMT+0100 (CET)

这对我来说很有趣。我可以同意最后一点，因为报告明确指出：

Sat Jan 01 2000 00:00:00 GMT+0100 (CET)
Sat Jan 01 0 01:00:00 GMT+0100 (CET)
Sat Jan 01 0 01:00:00 GMT+0100 (CET)
Mon Jan 01 1900 00:00:00 GMT+0100 (CET)

年度

表示年份的整数值。从0到99的值映射到1900年到1999年。请参见下面的示例

我也能理解第二个和第三个结果，因为这取决于时间。他们确实接受

4*位

作为一年，因此

0000

应该是RFC规范规定的0年（尽管我没有完全阅读）

只是有点奇怪，其中一个

Date

构造函数可以用于1900以上的日期，而另一个构造函数允许更大范围的日期（RFC）

---

然而，我不明白第一个结果。2000年从何而来？我知道这个日期并不合适，但它不应该返回无效日期来代替这个日期吗？

这是特定于浏览器的

这是JavaScript和浏览器不一致导致程序员额外痛苦的另一个领域。一些浏览器将所有两位数的年份解释为19xx，因此

新日期（'1/1/49'）

给出1949年1月1日，而

新日期（'1/1/50'）

给出1950年1月1日。其他人使用1950年作为“两位数的年份截止日期”，因此

新日期（'1/1/49'）

给出了2049年1月1日，

新日期（'1/1/50'）

给出了1950年1月1日

-

您必须记住，您引用的RFC文档是在2001年4月发布的。20世纪才刚刚结束。我想，为了使20世纪的年代更加现代化，一些浏览器现在将0映射到49，即2000年到2049年。然而，50仍然被映射为1950年

上面引用的文章还提供了一些测试结果：

以下是结果的简要总结：

• IE9：未找到两位数的年份截止值。00年=1900年
• 铬24.0：两位数年份在49和50之间变化。00年=2000年
• Opera：未找到两位数的年份截止值。00年=1900年
• Firefox：没有发现两位数的年份截止值。00年=1900年
• 狩猎：两位数的年份在49和50之间变化。00年=2000年

---

不过这篇文章现在已经过时了，所以我想上面Opera和Firefox的数据可能已经改变了。

我想你已经在Chrome上测试过了。在不同的浏览器中，最上面的

新日期（“0000-1-1”）

不同。在Firefox中，它输出一个无效的日期，在IE中，它输出1900年12月1日。以下是V8日期分析器的代码，其中可能包含一些线索：啊，是的，很抱歉我在Chrome中测试了它：）应该在其他浏览器中测试。以毫秒为单位的日期可以用于一致性

新日期（-621672192e5）

，或

新日期（“0000”）

至少有4位数字。如果您想避免使用浏览器特定的日期，您应该使用一个像样的库，如Moment.js，而不是依赖浏览器的日期类来正确执行。@Simba是的，我们不打算使用这个。我只是注意到了它，因为在我们的旧数据库系统中，

0000-01-01

实际上是日期的

NUL

值。但是我们忘了处理这个问题，所以现在我们有了一个带有

0000-01-01

的jQuery UI日期选择器，我们注意到通过在其中输入

0000-1-1

，它将日期选择器设置为2000，所以我开始玩。不管怎样，刚刚在Mac上测试了它，Firefox和Safari都返回了

无效日期。Opera现在和Chrome在同一个引擎上，所以它们有相同的结果。在我的虚拟机上，IE10显示1900，但第二个和第三个选项有问题，第二个选项显示1900，第三个选项显示
NaN
。谢谢你把它清理掉！