JS 的 Date API 究竟是個什麼陰間東西

Date API 你們確定都有用過，雖然更多時候關於日期的處理都交給了 dayjs 或者 moment。

但咱們確定免不了去直接使用原生 API，這時候你可能會免不了爆一句粗口「什麼陰間玩意？」，接下來咱們來看看到底這個 API 很差用到哪裏去。

首先咱們先了解下 Date 支持哪些類型的傳參：

new Date();
new Date(value);
new Date(dateString);
new Date(year, monthIndex [, day [, hours [, minutes [, seconds [, milliseconds]]]]]);
複製代碼

瞭解完參數類型，就直接用起來咯：

沒啥毛病，符合預期，不傳參就獲取當前系統時間。

那麼咱們換種寫法，傳入字符串呢？

小小的腦殼充滿了問號，明明我傳入一樣的日期，無非格式變了一下，爲啥輸出的內容卻徹底不同？

筆者這裏解釋下，當咱們輸入第一種格式時，內部會幫咱們解析成當前時區所對應的協調世界時（UTC），也就是零點加八小時。

而當咱們輸入第二種格式時，內部會幫咱們解析成當前時區的零點。

到這裏其實筆者已經有點懵逼了，不踩過這種坑鬼知道會有這樣的不一樣。

你覺得這樣就結束了？天真了，咱們再來看這種寫法：

好傢伙，我這傳的明明是七月份，咋的給我解析成八月份了？？？

這看起來是個 Bug，實際上算是一個老傳統，在好久以前的編程語言裏確實以 0 開頭做爲某些時間的起始位：

以上內容你們能夠在 Linux 的文檔中閱讀到。

文章到這裏尚未結束，我們再來換個寫法看看：

這第一個寫法筆者還能理解一點，畢竟年份從 1900 年開始計數，可是爲啥換成數組的寫法你就給我變成了 2032 年啊！

筆者這裏也就不考古了，反正打死不這樣寫就好了。

---

更新：這裏讀者解釋是由於 [32, 10, 4] 被轉換爲了字符串，也就是 new Date('32, 10, 4')，所以結果如圖所示。

---

那麼多坑，心累了，之後就只用 new Date() 吧，但其實也很差意思，單用這個你說不定也能踩到一個坑。

舉個場景，咱們在服務端給接口 setCookie 的時候都會設置一個 expires 字段表明這個 Cookie 的有效時間，此時若是你的 expires 字段是以 new Date() 生成的話，千萬記得要作一次轉換。

好比說咱們利用 new Date() 獲取了一個時間，你們能夠看到輸出是帶有中文的：

此時若是你把這個時間去作 setCookie 的話，服務端就會報一個 TypeError 的錯誤：invalid character in header content ["set-cookie"]，這是由於咱們設置的值裏存在中文。

所以咱們須要對這個時間作一次轉換獲得一個不包含中文的時間字符串。

講了那麼多，難道原生 API 真的沒救了？只能全用庫了麼？這倒也不是，TS39 也知道如此陰間的 API 很差用，所以搞了 proposal-temporal 這個提案來解決問題，算是融合了目前日期處理庫的功能。

可是等這個提案兼容大部分瀏覽器也不知道何時呢，仍是繼續 dayjs 吧。