2012-01-01 82 views
4

跨瀏覽器(Firefox &鉻)和跨平臺驗證(OSX &的Linux):爲什麼Date.parse('2012-01-01')和Date.parse('1/1/2012')返回不同的值?

> Date.parse('2012-01-01') 
1325376000000 
> Date.parse('1/1/2012') 
1325394000000 

相關: https://github.com/portablemind/compass_agile_enterprise/wiki/Javascript-Date.parse-bug%3F

+0

對於使用第二種格式,即使它似乎與您測試的瀏覽器一起使用,我也會小心謹慎,因爲對於像「1/2/2012」這樣的日期 - 我讀了2月1日的日期,但我收集美國人會把它作爲1月2日 - 瀏覽器可能會考慮或不考慮語言環境... – nnnnnn 2012-01-01 10:22:26

+0

如果是用戶輸入(這是我的情況)很難保持謹慎 – Troy 2012-02-03 20:00:07

回答

3

格式2012-01-01被解釋爲ISO 8601符合性,以及Z時區(+00,世界時間協調)是隱含的。如果接受(這取決於實施),格式爲1/1/2012,則作爲當地時間。

要獲得更一致的結果,請使用像Globalize.js這樣的庫。

+1

或者您可以將Z添加到結束。 – blockhead 2012-01-01 08:14:54

1

如果您將Z添加到最後,這將保證您始終表示UTC。

> Date.parse('2012-01-01') 
1325376000000 
> Date.parse('1/1/2012') 
1325394000000 
> Date.parse('1/1/2012 Z') 
1325376000000 
+0

不,根據ECMAScript標準,需要使用Date.parse()解析ISO 8601格式,例如2012-01-01Z(帶或不帶Z),但不需要識別其他格式,例如2012年1月1日:「如果字符串不符合[ISO 8601]格式,該函數可能會回退到任何特定於實現的啓發式或實現特定的日期格式。」 – 2012-01-01 10:03:35

+0

我只是說,實際上,如果您將Z in,瀏覽器肯定知道你需要UTC的時間。 – blockhead 2012-01-01 10:12:16

0

我已經寫了如下代碼:

var a = Date.parse('2012-01-01'); 
    var b = Date.parse('2012-01-01'); 
    var c = Date.parse('1/1/2012'); 

    alert(a + ' - ' + b + ' - ' + c); 

而結果是,

13253.76億 - 13253.76億 - 13253.76億

爲什麼我寫了相同的代碼的原因和b是,http://www.w3schools.com/jsref/jsref_parse.asp說,Date.parse返回一個毫秒值,無論這些行之間是否經過時間。

我使用Firefox 9.0.1,結果是正確的。

+0

IE8返回:NaN - NaN - 1325376000000 Safari 5.1.2返回:NaN - NaN - 1325376000000 – tcak 2012-01-01 08:19:30

相關問題