今天遇到一个怪异的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的结果。
这是我第一次遇到这样的问题,也提醒自己尽管现代浏览器已经越来越标准化了,兼容性的问题还是会在某些不起眼的地方出现,给你埋下一个又一个难以察觉的坑。
1. 正确的做法
2. 知识点总结
'2015-05-04'是无法被各个浏览器中,使用new Date(str)来正确生成日期对象的。 正确的用法是'2015/05/05'.