2

在浏览器端（Safari 5.0.1）计算遥远的未来日期时有一些可疑之处，将字符串传递给Date()构造函数：

我将其缩小到 22034 年的 2 月至 3 月的过渡：

d = new Date('1 Mar 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

在任何以后的 date中提供它，构造函数总是返回一个 Date 对象关闭一天！

更早的日期呢？二月的最后一天看起来不错：

d=new Date('28 Feb 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

我的直觉告诉我，这看起来像是与闰年相关的错误。但是这里的模式是什么，这个错误的解释是什么？

编辑：

如果我们要求 2 月 29 日怎么样？

d=new Date('29 Feb 22034')
Wed Mar 01 22034 00:00:00 GMT+0000 (GMT)

这将返回 2 月 + 1 天的最后一天（其标准行为）。

4

1 回答 1

1

这是因为您提供的日期格式new Date()是非标准的。您得到任何东西的事实是因为 Safari 正在帮您一个忙。（有关有效格式，请参阅规范的第 15.9.1.15 节；基本上是简化的 ISO-8601。并且有任何解析日期/时间字符串的标准是相对较新的 [第 5 版]。）

如果您使用标准构造函数，例如new Date (22034, 2, 1)（月份从零开始，即 22034 年 3 月 1 日），它可以正常工作。您可以像这样测试它（实时副本）：

display("With non-standard string: " + new Date("1 Mar 22034"));
display("Using standard constructor: " + new Date(22034, 2, 1));

对我来说，使用 Safari for Windows 会导致：

使用非标准字符串：Tue Feb 28 22034 00:00:00 GMT+0000（GMT 标准时间）
使用标准构造函数：Wed Mar 01 22034 00:00:00 GMT+0000（GMT 标准时间）

如您所见，第一行显示了错误的日期，而第二行显示了正确的日期。

标准构造函数在 Chrome、Opera 和 Firefox（都在 Ubuntu 下）、IE6、IE7 和 IE8 中也能正常工作：http: //jsbin.com/ogiqu

如果 Safari 确实无法处理该日期（而不是无法可靠地解析您提供给它的非标准字符串），那将是一个令人惊讶的 Safari 特定错误。从规范的第 15.9.1.1 节：

自 1970 年 1 月 1 日 UTC 以来，时间在 ECMAScript 中以毫秒为单位进行测量。在时间值中，闰秒被忽略。假设每天正好有 86,400,000 毫秒。ECMAScript Number 值可以表示从 –9,007,199,254,740,991 到 9,007,199,254,740,991 的所有整数；该范围足以测量从 1970 年 1 月 1 日 UTC 起大约 285,616 年（向前或向后）内的任何时刻的毫秒精度。

但是，当您不要求它离开滑雪道时，Safari 似乎可以很好地处理它，显然问题出在非标准字符串的解析代码中。

于 2010-11-30T16:47:54.753 回答