Date.parse和new Date(str)的兼容性问题

最新推荐文章于 2023-11-30 16:24:39 发布

原创最新推荐文章于 2023-11-30 16:24:39 发布 · 6.7k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#webkit #safari #chrome #firefox #浏览器

javascript 专栏收录该内容

52 篇文章

订阅专栏

本文探讨了Date.parse()方法在不同浏览器中的表现差异，尤其是在Chrome与Firefox中的兼容性问题。发现Date.parse('foo-bar2014')在Chrome中返回有效日期，在Firefox中返回NaN。文章还提供了解决方案，通过修改日期格式提高兼容性。

今天遇到一个怪异的BUG，一路跟踪到isNaN(Date.parse(str))这句上，这里的意图是探测str是否是合法的日期字符串。根据MDN的定义：

The Date.parse() method parses a string representation of a date, and returns the number of milliseconds since January 1, 1970, 00:00:00 UTC.

只要是合法的日期字符串，就会返回一个UTC日期。那么要是不合法呢？MDN上有一个例子：

Date.parse('foo-bar 2014');// returns: NaN

这么看来他的做法应该是可行的，但为啥出现问题了呢？我在自己的电脑上试了下，Date.parse('foo-bar 2014')返回的是1388530800000！于是一想，前端组里好像只有我是常用Chrome的，其他人都是Firefox，难道是兼容性的问题？

于是换浏览器使劲测了测，果然如此。在Firefox中，字符串中只要出现非日期字母就会立即判定为非法日期字符串，而在当前版本的Chrome中，只要字符串最后的那部分是数字，并且和前面有空格分隔，Date.parse就会取空格和数字部分，并按这个部分给出一个日期。于是在Chrome下，Date.parse('foo-bar 2014')与Date.parse(' 2014')所得的结果是一致的。但如果数字前面不是空格，如'foo-bar-2014，则会同Firefox一样返回NaN。

WebKit系内核的safari没有这个问题，行为与Firefox一致。其他浏览器则还没来得及测，有windows的朋友可以试试IE的结果。

这是我第一次遇到这样的问题，也提醒自己尽管现代浏览器已经越来越标准化了，兼容性的问题还是会在某些不起眼的地方出现，给你埋下一个又一个难以察觉的坑。

上一篇文章中说的就有一种方法将日期转为毫秒数的Date.parse()，同样测试后在移动端浏览器都显示为NAN，不能正常使用，继续探寻新的方法。

对于new Date(str)；

在页面中，我们使用了一个时间组件，但是发现在Firefox下是无法正常工作的，同样在移动端浏览器也是不识别的，返回结果都是NAN，但是在Chrome下是可以正常运行的。问题出在哪里呢？

1. 正确的做法

[html] view plain copy 
    
 
 var time1 = (timestart+' 00:00:00').toString();  
 var time2 = (timeend+' 23:59:59').toString();  
 timestart = new Date(Date.parse(str.replace(/-/g,"/"))).getTime();  
 timeend = new Date(Date.parse(str.replace(/-/g,"/"))).getTime();  