今天遇到一個怪異的BUG捌臊， 一路跟蹤到isNaN(Date.parse(str))這句上蜻拨，詢問同事后得知這里的意圖是探測str是否是合法的日期字符串奠货。根據(jù)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
這么看來他的做法應(yīng)該是可行的移宅，但為啥出現(xiàn)問題了呢？我在自己的電腦上試了下椿疗，Date.parse('foo-bar 2014')返回的是1388530800000漏峰！于是一想，前端組里好像只有我是常用Chrome的届榄，其他人都是Firefox浅乔，難道是兼容性的問題？
于是換瀏覽器使勁測了測铝条，果然如此靖苇。在Firefox中，字符串中只要出現(xiàn)非日期字母就會立即判定為非法日期字符串班缰，而在當(dāng)前版本的Chrome中贤壁，只要字符串最后的那部分是數(shù)字，并且和前面有空格分隔埠忘，Date.parse就會取空格和數(shù)字部分脾拆，并按這個部分給出一個日期馒索。于是在Chrome下，Date.parse('foo-bar 2014')與Date.parse(' 2014')所得的結(jié)果是一致的名船。但如果數(shù)字前面不是空格绰上，如'foo-bar-2014，則會同F(xiàn)irefox一樣返回NaN渠驼。
最后還借同事的mac測了下蜈块，發(fā)現(xiàn)WebKit系內(nèi)核的safari沒有這個問題，行為與Firefox一致迷扇。其他瀏覽器則還沒來得及測疯趟，有windows的朋友可以試試IE的結(jié)果。
這是我第一次遇到這樣的問題谋梭，也提醒自己盡管現(xiàn)代瀏覽器已經(jīng)越來越標(biāo)準(zhǔn)化了信峻，兼容性的問題還是會在某些不起眼的地方出現(xiàn)，給你埋下一個又一個難以察覺的坑瓮床。
