摘要：然而由于地球的不規(guī)則自轉(zhuǎn)，導(dǎo)致時(shí)間有誤差，因此目前已不被當(dāng)作標(biāo)準(zhǔn)時(shí)間使用。而在航空上，所有使用的時(shí)間劃一規(guī)定是協(xié)調(diào)世界時(shí)。

一個(gè)多月沒更新了- -偷懶中。這個(gè)東西其實(shí)很早之前就在整理了，不過后來發(fā)現(xiàn)自己不少地方?jīng)]弄明白，然后就一直卡那邊了（其實(shí)就是不想寫吧），想了下反正是給自己熟悉js的原生API而已，所以也沒必要太鉆牛角尖，也不一定要多完整，因此就當(dāng)是Date()函數(shù)的一個(gè)冷門知識點(diǎn)小補(bǔ)充吧。這篇文章主要講Date()的字符串與時(shí)間戳轉(zhuǎn)換以及用戶時(shí)間本地化,可能內(nèi)容上比較亂（不然也不會(huì)卡我一個(gè)月時(shí)間了），見諒

ps：由于Date()是js原生函數(shù)，不同瀏覽器的解析器對其實(shí)現(xiàn)方式并不同，所以返回值也會(huì)有所區(qū)別。本文測試未特別申明瀏覽器的情況下，均是指win7 x64+chrome 44.0.2403.155 (正式版本) m （32 位）版本

Date()直接返回當(dāng)前時(shí)間字符串，不管參數(shù)是number還是任何string

Date();
Date("sssss");
Date(1000);
//Fri Aug 21 2015 15:46:21 GMT+0800 (中國標(biāo)準(zhǔn)時(shí)間)

而new Date()則是會(huì)根據(jù)參數(shù)來返回對應(yīng)的值，無參數(shù)的時(shí)候，返回當(dāng)前時(shí)間的字符串形式；有參數(shù)的時(shí)候返回參數(shù)所對應(yīng)時(shí)間的字符串。new Date()對參數(shù)不管是格式還是內(nèi)容都要求,且只返回字符串,

new Date();
//Fri Aug 21 2015 15:51:55 GMT+0800 (中國標(biāo)準(zhǔn)時(shí)間)

new Date(1293879600000);
new Date("2011-01-01T11:00:00")
new Date("2011/01/01 11:00:00")
new Date(2011,0,1,11,0,0)
new Date("jan 01 2011,11 11:00:00")
new Date("Sat Jan 01 2011 11:00:00")
//Sat Jan 01 2011 11:00:00 GMT+0800 (中國標(biāo)準(zhǔn)時(shí)間)

new Date("sss");
new Date("2011/01/01T11:00:00");
new Date("2011-01-01-11:00:00")
new Date("1293879600000");
//Invalid Date

new Date("2011-01-01T11:00:00")-new Date("1992/02/11 12:00:12")
//596069988000

從上面幾個(gè)測試結(jié)果可以很容易發(fā)現(xiàn)

new Date()在參數(shù)正常的情況只會(huì)返回當(dāng)前時(shí)間的字符串(且是當(dāng)前時(shí)區(qū)的時(shí)間)

new Date()在解析一個(gè)具體的時(shí)間的時(shí)候，對參數(shù)有較嚴(yán)格的格式要求，格式不正確的時(shí)候會(huì)直接返回Invalid Date，比如將number類的時(shí)間戳轉(zhuǎn)換成string類的時(shí)候也會(huì)導(dǎo)致解析出錯(cuò)

雖然new Date()的返回值是字符串，然而兩個(gè)new Date()的結(jié)果字符串是可以直接相減的，結(jié)果為相差的毫秒數(shù)。

那么，new Date()能接受的參數(shù)格式到底是什么標(biāo)準(zhǔn)呢?（相對于嚴(yán)格要求的多參數(shù)傳值方法。非嚴(yán)格的單參數(shù)(數(shù)字日期表示格式)更常用且更容易出錯(cuò)，所以下文只考慮單參數(shù)數(shù)字時(shí)間字符串轉(zhuǎn)換的情況)

這個(gè)是最簡單的也是最不容易出錯(cuò)的。當(dāng)然唯一的缺點(diǎn)大概就是對開發(fā)者不直觀，無法一眼看出具體日期。
需要注意的以下兩點(diǎn):

js內(nèi)的時(shí)間戳指的是當(dāng)前時(shí)間到1970年1月1日00:00:00 UTC對應(yīng)的毫秒數(shù)，和unix時(shí)間戳不是一個(gè)概念，后者表示秒數(shù)，差了1000倍

new Date(timestamp)中的時(shí)間戳必須是number格式，string會(huì)返回Invalid Date。所以比如new Date("11111111")這種寫法是錯(cuò)的

不大清楚這種該怎么描述，就是類似YYYY/MM/DD HH:mm:SS這種。下文以dateString代指。
new Date(dateString)所支持的字符串格式需要滿足RFC2822標(biāo)準(zhǔn)或者ISO 8601標(biāo)準(zhǔn)
這兩種標(biāo)準(zhǔn)對應(yīng)的格式分別如下:

RFC2822 標(biāo)準(zhǔn)日期字符串

YYYY/MM/DD HH:MM:SS ± timezon(時(shí)區(qū)用4位數(shù)字表示)
// eg 1992/02/12 12:23:22+0800

RFC2822還有別的格式，不過上面這個(gè)是比較常用的（另外這標(biāo)準(zhǔn)太難啃了，實(shí)在沒耐心啃完，所以也就沒太深入)。RFC2822標(biāo)準(zhǔn)本身還有其他的非數(shù)字日期表達(dá)方式，不過不在這個(gè)話題討論范圍內(nèi)了,略過

ISO 8601標(biāo)準(zhǔn)日期字符串

 YYYY-MM-DDThh:mm:ss ± timezone(時(shí)區(qū)用HH:MM表示)

 1997-07-16T08:20:30Z
 // “Z”表示UTC標(biāo)準(zhǔn)時(shí)區(qū)，即"00:00",所以這里表示零時(shí)區(qū)的`1997年7月16日08時(shí)20分30秒`
 //轉(zhuǎn)換成位于東八區(qū)的北京時(shí)間則為`1997年7月17日16時(shí)20分30秒`

 1997-07-16T19:20:30+01:00
 // 表示東一區(qū)的1997年7月16日19時(shí)20秒30分，轉(zhuǎn)換成UTC標(biāo)準(zhǔn)時(shí)間的話是1997-07-16T18:20:30Z
 

日期和時(shí)間中間的T不可以被省略，一省略就出錯(cuò)。

雖然在chrome瀏覽器上時(shí)區(qū)也可以用+0100這種RFC2822的形式來表示，然而IE上不支持這種混搭寫法，所以用ISO8601標(biāo)準(zhǔn)形式表示的時(shí)候時(shí)區(qū)要用+HH:MM

單單從格式上來說，兩者的區(qū)別主要在于分隔符的不同。不過需要注意的是，ISO 8601標(biāo)準(zhǔn)的兼容性比RFC2822差得多（比如IE8和iOS均不支持前者。我知道IE8很多人會(huì)無視，不過iOS也有這個(gè)坑的話，各位或多或少會(huì)謹(jǐn)慎點(diǎn)了吧？)，所以一般情況下建議用RFC 2822格式的。
不過需要注意的是，在未指定時(shí)區(qū)的前提下，對于只精確到day的日期字符串，RFC 2822返回結(jié)果是以當(dāng)前時(shí)區(qū)的零點(diǎn)為準(zhǔn)，而ISO8601返回結(jié)果則會(huì)以UTC時(shí)間的零點(diǎn)為標(biāo)準(zhǔn)進(jìn)行解析。
例如：

//RFC2822：
new Date("1992/02/13") //Thu Feb 13 1992 00:00:00 GMT+0800 (中國標(biāo)準(zhǔn)時(shí)間)
//ISO8601:
new Date("1992-02-13") //Thu Feb 13 1992 08:00:00 GMT+0800 (中國標(biāo)準(zhǔn)時(shí)間)

然而上面這個(gè)只是ES5的標(biāo)準(zhǔn)而已，在ES6里這兩種形式都會(huì)變成當(dāng)前時(shí)區(qū)的零點(diǎn)為基準(zhǔn)¹
不管你們崩潰沒，反正我是已經(jīng)想死了
關(guān)于跨瀏覽器的dataString解析情況，還可以參考這個(gè)頁面:
JavaScript and Dates, What a Mess!

所以對于時(shí)間字符串對象，個(gè)人意見是要么用RFC2822形式，要么自己寫個(gè)解析函數(shù)然后隨便你傳啥格式進(jìn)來。

這里的時(shí)間格式化值得是將時(shí)間字符串轉(zhuǎn)換成毫秒數(shù)的過程。js原生的時(shí)間格式化函數(shù)有Date.parse、Date.prototype.valueOf、Date.prototype.getTime、Number(Date)、+Date（還有個(gè)Date.UTC方法，然而對參數(shù)要求嚴(yán)格，不能直接解析日期字符串，所以略過)
這5個(gè)函數(shù)從功能上來說一模一樣，但是具體的效率如何呢？我寫了個(gè)檢測頁面，諸位也可以自己測試下。
http://codepen.io/chitanda/pen/NqeZag/

    function test(dateString,times,func){
    var startTime=window.performance.now();
    // console.log("start="+startTime.getTime());
    for (var i = 0; i < times; i++) {
        func(dateString);//這里填寫具體的解析函數(shù)
    };
    var endTime=window.performance.now();
    // console.log("endTime="+endTime.getTime());
    var gapTime=endTime-startTime;
      console.log("一共耗時(shí):"+gapTime+"ms");
    // console.log("時(shí)間字符串"+dateString);
    return gapTime;
}

之所以這里用window.performance.now()而不用new Date(),是因?yàn)榍罢呔_度遠(yuǎn)比后者高。后者只能精確到ms。會(huì)對結(jié)果造成較大影響

單次執(zhí)行50W次時(shí)間格式化函數(shù)，并重復(fù)測試100次，最后的結(jié)果如下:
（表格中的數(shù)字為單次執(zhí)行50W次函數(shù)的平均結(jié)果。單位為毫秒)

從這個(gè)表格可以很容易得出以下結(jié)論：

從計(jì)算效率上來說，Date.prototype.getTime()≈Date.prototype.valueOf()>+Date≈Number(Date)>>Date.parse()

從代碼書寫效率上來說，對于少量的時(shí)間格式化計(jì)算，用+Date()或者Number(Date)即可。而若頁面內(nèi)有大量該處理，則建議用Date原生的函數(shù)Date.prototype.getTime()或者Date.prototype.valueOf().只有Date.parse,找不到任何使用的理由。

這個(gè)結(jié)果和計(jì)算機(jī)的計(jì)算性能以及瀏覽器有關(guān)，所以具體數(shù)字可能會(huì)有較大偏差，很正常。然而幾個(gè)函數(shù)結(jié)果的時(shí)間差大小順序并不會(huì)變。

codepen的在線demo限制比較大，對于這個(gè)測驗(yàn)個(gè)人建議最好將源代碼復(fù)制到本地文件然后進(jìn)行測試

這個(gè)不是啥重要東西，單純當(dāng)課外知識吧。

GMT即「格林威治標(biāo)準(zhǔn)時(shí)間」(Greenwich Mean Time，簡稱G.M.T.)，指位于英國倫敦郊區(qū)的皇家格林威治天文臺的標(biāo)準(zhǔn)時(shí)間，因?yàn)楸境踝游缇€被定義為通過那里的經(jīng)線。然而由于地球的不規(guī)則自轉(zhuǎn)，導(dǎo)致GMT時(shí)間有誤差，因此目前已不被當(dāng)作標(biāo)準(zhǔn)時(shí)間使用。

UTC是最主要的世界時(shí)間標(biāo)準(zhǔn)，是經(jīng)過平均太陽時(shí)(以格林威治時(shí)間GMT為準(zhǔn))、地軸運(yùn)動(dòng)修正后的新時(shí)標(biāo)以及以「秒」為單位的國際原子時(shí)所綜合精算而成的時(shí)間。UTC比GMT來得更加精準(zhǔn)。其誤差值必須保持在0.9秒以內(nèi)，若大于0.9秒則由位于巴黎的國際地球自轉(zhuǎn)事務(wù)中央局發(fā)布閏秒，使UTC與地球自轉(zhuǎn)周期一致。不過日常使用中，GMT與UTC的功能與精確度是沒有差別的。
協(xié)調(diào)世界時(shí)區(qū)會(huì)使用“Z”來表示。而在航空上，所有使用的時(shí)間劃一規(guī)定是協(xié)調(diào)世界時(shí)。而且Z在無線電中應(yīng)讀作“Zulu”（可參見北約音標(biāo)字母），協(xié)調(diào)世界時(shí)也會(huì)被稱為“Zulu time”。

首先需要注意一點(diǎn)，瀏覽器獲取當(dāng)前用戶所在的時(shí)區(qū)等信息只和系統(tǒng)的日期和時(shí)間設(shè)置里的時(shí)區(qū)以及時(shí)間有關(guān)。區(qū)域和語言設(shè)置影響的是瀏覽器默認(rèn)時(shí)間函數(shù)(Date.prototype.toLocaleString等)顯示的格式，不會(huì)對時(shí)區(qū)等有影響。以window為例，控制面板時(shí)鐘、語言和區(qū)域中的兩個(gè)子設(shè)置項(xiàng)目的區(qū)別如下：

日期和時(shí)間:設(shè)置當(dāng)前用戶所處的時(shí)間和時(shí)區(qū)，瀏覽器獲取到的結(jié)果以此為準(zhǔn)，哪怕用戶的設(shè)置時(shí)間和時(shí)區(qū)是完全錯(cuò)誤的。比如若東八區(qū)的用戶將自己的時(shí)區(qū)設(shè)置為東9區(qū)，瀏覽器就會(huì)將視為東9區(qū);時(shí)間數(shù)據(jù)上同理。這里的設(shè)置會(huì)影響Date.prototype.getTimezoneOffset、new Date()的值

區(qū)域和語言:主要是設(shè)置系統(tǒng)默認(rèn)的時(shí)間顯示方式。其子設(shè)置的格式會(huì)影響Date.prototype.toLocaleString方法返回的字符串結(jié)果

Date有個(gè)Date.prototype.toLocaleString()方法可以將時(shí)間字符串返回用戶本地字符串格式，這個(gè)方法還有兩個(gè)子方法Date.prototype.toLocaleDateString和Date.prototype.toLocaleTimeString，這兩個(gè)方法返回值分別表示日期和時(shí)間，加一起就是Date.prototype.toLocaleString的結(jié)果。
這個(gè)方法的默認(rèn)參數(shù)會(huì)對時(shí)間字符串做一次轉(zhuǎn)換，將其轉(zhuǎn)換成用戶當(dāng)前所在時(shí)區(qū)的時(shí)間，并按照對應(yīng)的系統(tǒng)設(shè)置時(shí)間格式返回字符串結(jié)果。然而不同瀏覽器對用戶本地所使用的語言格式的判斷依據(jù)是不同的。
IE:獲取系統(tǒng)當(dāng)前的區(qū)域和語言-格式中設(shè)置的格式，依照其對應(yīng)的格式來顯示當(dāng)前時(shí)間結(jié)果;IE瀏覽器實(shí)時(shí)查詢該系統(tǒng)設(shè)置（即你在瀏覽器窗口打開后去更改系統(tǒng)設(shè)置也會(huì)引起返回格式變化）
FF：獲取方式和結(jié)果與IE瀏覽器相同，區(qū)別在于FF只會(huì)在瀏覽器進(jìn)程第一次啟動(dòng)的時(shí)候獲取一次系統(tǒng)設(shè)置，中間不管怎么系統(tǒng)設(shè)置怎么變化，F(xiàn)F都無法獲取到當(dāng)前系統(tǒng)設(shè)置。除非重啟FF瀏覽器。
Chrome:獲取方式和以上兩個(gè)都不同。chrome無視系統(tǒng)的區(qū)域和語言-格式格式，只依照自己瀏覽器的界面設(shè)置的菜單語言來處理。(比如英文界面則按系統(tǒng)"en-US"格式返回字符串，中文界面則按系統(tǒng)"zh-CN"格式返回結(jié)果)
綜上可得：

chrome下瀏覽器語言設(shè)置優(yōu)先系統(tǒng)語言設(shè)置。而IE和FF則是系統(tǒng)語言設(shè)置優(yōu)先瀏覽器語言設(shè)置,不管瀏覽器界面語言是什么，他們只依照系統(tǒng)設(shè)置來返回格式。（沒有MAC，所以不知道safari是啥情況，等以后看情況補(bǔ)充吧)
另外，不同瀏覽器對toLocaleString返回的結(jié)果也是不同的，IE瀏覽器嚴(yán)格遵守系統(tǒng)設(shè)置，而chrome和FF會(huì)有自己內(nèi)置的格式來替換。

這小節(jié)貌似有點(diǎn)跑題，然而不說明下的很容易和上面提到的瀏覽器設(shè)置的語言混淆，所以也拿出來說一下。
需要注意瀏覽器的語言設(shè)置和界面語言設(shè)置不是一回事。
瀏覽器的語言設(shè)置設(shè)置的是瀏覽器發(fā)送給服務(wù)器的Request Header里的Accept-Language的值，這個(gè)值可以告訴服務(wù)器用戶的喜好語言，對于某些跨國網(wǎng)站，服務(wù)器可以以此為依舊來返回對應(yīng)語言的頁面（不過實(shí)際應(yīng)用上這個(gè)限制比較大，大部分網(wǎng)站還是根據(jù)IP來判斷用戶來源的，或者直接讓用戶自己選擇）
對于各大瀏覽器而言，這個(gè)設(shè)置的更改也是比較顯性，容易找到的。
IE： Internet選項(xiàng)-語言
FF： 選項(xiàng)-內(nèi)容-語言
chrome:設(shè)置-顯示高級設(shè)置-語言-語言和輸入設(shè)置...
上面這里的設(shè)置不會(huì)影響到瀏覽器的界面語言設(shè)置，以國內(nèi)大部分用戶而言，即不管你怎么設(shè)置這里的語言選項(xiàng)，瀏覽器菜單等默認(rèn)都會(huì)是以中文顯示的.
而瀏覽器的界面語言設(shè)置一般來說則藏的深得多，沒那么容易找到。
IE：
卸載前面安裝過的瀏覽器語言包，去微軟官網(wǎng)下載對應(yīng)的IE瀏覽器語言包安裝。（和安裝的語言包有關(guān)。系統(tǒng)界面語言和該語言包相同的情況下，變?yōu)樵撜Z言。否則以安裝的語言包為準(zhǔn)。）
FF：地址欄輸入about:config，然后找到general.useragent.locale字段，修改對應(yīng)字段即可。
chrome：設(shè)置-顯示高級設(shè)置-語言-語言和輸入設(shè)置...

對于獲取這兩種設(shè)置，js原生方法支持度都比較一般:
IE下的navigator方法有四種和language有關(guān)的方法，區(qū)別如下:
假設(shè)系統(tǒng)語言為 ja-JP，系統(tǒng)unicode語言為zh-CN日期格式為nl-NL,瀏覽器語言設(shè)置（accept-language)為de,瀏覽器界面語言為en-US（其他條件不變，瀏覽器界面語言改為zh-CN的時(shí)候結(jié)果也是一樣)，

window.navigator.language
//"nl-NL"
window.navigator.systemLanguage
//"zh-CN"(設(shè)置中的非unicode程序所使用語言選項(xiàng))
window.navigator.userLanguage
//"nl-NL"
window.navigator.browserLanguage
//"ja-JP"（系統(tǒng)菜單界面語言）
window.navigator.languages
//undefined

chrome下，當(dāng)瀏覽器界面語言為zh-CN,accept-language首位為en-US的時(shí)候：

window.navigator.language
//"zh-CN"
window.navigator.languages
//["en-US", "en", "zh-CN", "zh", "ja", "zh-TW", "de-LI", "de", "pl"]
//當(dāng)界面語言改為"en-US"時(shí)
window.navigator.language
//"en-US"（瀏覽器界面語言)

FF下，當(dāng)瀏覽器界面語言為zh-CN,accept-language首位為en-US的時(shí)候：

window.navigator.language
//"en-US"
window.navigator.languages
//["en-US", "zh-CN", "de", "zh", "en"]
//當(dāng)界面語言改為"en-US",`accept-language`首位為`zh-CN`的時(shí)候
window.navigator.language
//"zh-CN"（`accept-language`首選值)
window.navigator.languages
//["zh-CN", "de", "zh", "en-US", "en"]

從上面的測試結(jié)果可以很明顯的發(fā)現(xiàn)IE瀏覽器的這幾個(gè)函數(shù)都是獲取系統(tǒng)信息的，無法獲取到前面提到的兩個(gè)瀏覽器層面上的設(shè)置。（這幾個(gè)函數(shù)具體含義還有疑問的可以參考MSDN官方文檔）

window.navigator.language這個(gè)函數(shù)雖然三個(gè)瀏覽器都可以兼容，然而代表的意義完全不同。IE下該函數(shù)返回系統(tǒng)設(shè)置的時(shí)間顯示格式所遵守的標(biāo)準(zhǔn)的地區(qū)代碼；chrome下返回瀏覽器界面語言；FF下返回accept-language的首選語言值

由此:

瀏覽器設(shè)置的語言即accept-language值，IE瀏覽器無法利用JS獲取。chrome和FF瀏覽器都可以利用window.navigator.languages來獲取，而FF還可以直接用   window.navigator.language直接獲取accept-language的首選語言值。所以對于accept-language，兼容性最好的獲取方法應(yīng)該是利用后端，發(fā)起一個(gè)ajax請求，分析header。而不是直接js來處理。

瀏覽器界面語言，IE和FF都無法利用js來獲取，chrome可以用window.navigator.language來獲取

系統(tǒng)級別的語言設(shè)置（系統(tǒng)菜單界面語言，系統(tǒng)設(shè)置的時(shí)間顯示格式），chrome和FF都無法用JS獲取到

這篇文章斷斷續(xù)續(xù)地寫了一個(gè)多月，不過由于對Date()函數(shù)的掌握不足因此個(gè)人感覺其實(shí)還是思路有點(diǎn)亂，所以文章看起來可能稍微有點(diǎn)跳躍性。不過用戶本地化那塊內(nèi)容確實(shí)用了不少心思去寫，希望對看到這篇文章的人有點(diǎn)幫助。

Date and Time Formats

Date and Time Specification(RFC2822)

Date.parse()-Differences in assumed time zone

JavaScript and Dates, What a Mess!

navigator object(IE瀏覽器私有l(wèi)anguage函數(shù)的解析)