Javascript新Date函數中的奇怪行為

Question

我試圖從javascript中的字符串中使Date對象成為對象，但是我在這里看到javascript解析日期字符串非常奇怪。

> new Date("2012-01-01");
Sun Jan 01 2012 07:00:00 GMT+0700 (ICT)

> new Date("01-01-2012");
Sun Jan 01 2012 00:00:00 GMT+0700 (ICT)

> new Date("2012-01-01") == new Date("01-01-2012")
false

我使用的是Chrome 32，您會看到它們相差7小時。 請告訴我這里發生了什么？

Answer 1

有關瀏覽器如何實現Date.parse （ spec ）的全部內容。 在傳遞給Date構造函數（ spec ）的字符串上調用該方法，然后首先嘗試將字符串與已知格式進行匹配以確定哪些值在哪里。 我希望不同的瀏覽器以略有不同的方式實現該決策樹，但是Chrome的實現可能假設"2012-01-01"版本是基於Zulu或GMT / UTC的ISO-8601標准的前綴，並包含時區（ "2012-01-01T00:00:00Z-07:00" ），而"01-01-2012"版本則是根據您當地的時區進行的本地化，因此無需理會它（ "01-01-2012 00:00:00" ），因此7小時時差基於ISO標准日期和本地化日期之間的7小時偏移量。 相反， Date.prototype.toString() （ spec ）應該顯示本地時間，並由Date構造函數返回，這就是為什么它在測試的兩個返回值中都進行了本地化的原因。

從Date.parse的規范 ：

該函數首先嘗試根據日期時間字符串格式（ 15.9.1.15 ）中調用的規則來解析字符串的格式。 如果字符串不符合該格式，則該函數可能會退回到任何特定於實現的啟發式或特定於實現的日期格式。 無法識別的字符串或包含字符串格式的非法元素值的日期將導致Date.parse返回NaN。

這意味着如果您不使用15.9.1.15中指定的完整ISO- 8601日期 ，瀏覽器可以隨時進行調整，也可以只給您NaN 。 盡管這是標准，但某些瀏覽器因實際上沒有遵循標准而臭名昭著，因此您可能會考慮通過自己解析數據並使用其他Date構造函數（ spec ）明確指定所有參數。

Answer 2

差異的原因在其他答案中進行了解釋。 避免此問題的一個好方法是解析字符串yoruself。 如果您希望將2012-01-01視為UTC，則：

function dateFromUTCString(s) {
  var s = s.split(/\D/);
  return new Date(Date.UTC(s[0], --s[1], s[2]));
}

如果要將其視為本地日期，則：

function dateFromString(s) {
  var s = s.split(/\D/);
  return new Date(s[0], --s[1], s[2]);
}