Question

如果我尝试使用以下语法解析日期：

var date1 = new Date(Date.parse('2013' + '/' + '02' + '/' + '29'));

它将于2013年3月1日返回。

var date1 = new Date(Date.parse('2013' + '/' + '02' + '/' + '30'));

它将于2013年3月2日返回。但如果我这样做

var date1 = new Date(Date.parse('2013' + '/' + '02' + '/' + '33'));

它将返回Invalid Date。

我的观点是，为什么所有这些日期都不会返回Invalid Date？

Answer 1

可能是糟糕的设计？（或者说是标准的狡猾实施）

使用JavaScript日期时总会出现问题 object esp cross browser（浏览器人员倾向于以自己的方式实现标准）。我可以让你忙碌一段时间，因为我多年来遇到的恐怖故事/问题 - 这就是为什么我们有像DateJs这样好的图书馆。

例如，这个（你的例子）甚至不是所有浏览器的行为，在IE9和最后一个片段中进行了测试返回2013年3月5日（与其他两个前面的代码段一样），在Chrome中，最后一个代码段返回无效日期。

但是，是的，我同意如果所有三个都返回无效日期会更有意义。

<强>更新（2015年1月8日）

似乎DateJs不再真正得到维护？你们可能宁愿考虑使用MomentJs作为替代方案。

Answer 2

正确解析Date.parse所需的唯一格式是ISO 8601的简化。您可以在ecma specification中阅读有关确切格式的更多详细信息。

Date.parse识别为日期的任何其他格式都是特定于实现的。您提到的格式不是上述标准的一部分，因此每个实现都可以为其提供任何结果。

当您传入大于31的月份中的某一天时，解析器会将其视为无效字符串，因此它将返回NaN。由于月度不规则，闰年，缺少秒，时区等各种问题，检查日期是否有效是非常困难的，因此将所有逻辑放在解析器中是不合理的。如果日期显然有效，它将转换为时间戳并由Date.parse返回，此时新的Date（）可以使用。

结论是，使用Date.parse的非标准格式是不可靠的，如果可能应该避免使用。

Answer 3

因为一天的值最多可以达到31号。

使用Date.parse确定有效日期不一致

3 个答案: