今天遇到一个怪异的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。
最后还借同事的mac测了下，发现WebKit系内核的safari没有这个问题，行为与Firefox一致。其他浏览器则还没来得及测，有windows的朋友可以试试IE的结果。
这是我第一次遇到这样的问题，也提醒自己尽管现代浏览器已经越来越标准化了，兼容性的问题还是会在某些不起眼的地方出现，给你埋下一个又一个难以察觉的坑。
