js new Date 創建時間默認是8點

 

起因

最近在寫一個頁面，需要用到時間控制。然后我通過new Date()傳入日期字符串創建了一個對象，並與當前時間做時間戳比較，結果12點剛過，就出問題了。舉個栗子

// 假設當前時間是2019年12月22日0點20分
new Date('2019-12-22').getTime() < new Date().getTime()
// 上面的結果是什么？正常來說應該是true吧，但不好意思啊，返回了false

 

百思不得其解，當時因為情況緊急，查出了上面的創建時間返回的內容並不是0點，而是8點

所以就強行在時間字符串上拼接了時間：new Date('2019-12-22 00:00:00').getTime(), 強行解決了這個問題。

然后又碰到了在IOS上不識別中橫線分割的時間字符串問題，講中橫線轉成了反斜杠。

當時臨時解決問題后的字符串大概長這樣：

new Date('2019/12/22 00:00:00').getTime() < new Date().getTime()

臨時解決問題。現在閑來無事，可以看看這個問題究竟是什么鬼？

嘗試

傳入不同的字符串格式，看看結果，我只嘗試了最常使用的兩種格式

驚訝的發現，-分割的字符串，被默認解析到了8點，而/分割的字符串，默認解析到了0點。這么說來，我之前有點多次一舉了，直接講-替換成/就可以了啊。

探究

那么為什么默認是8點呢？有沒有覺得8這個數字很值得關注，我們所在的時區是東八區，如果以GMT標准0點來算的話，在那個時間點，這里就是8點啊。

那我就可以這樣理解了，創建時間時，它默認時間確實是0點，但是是以GMT為基准的，所以將其轉換成本地時間就是8點。而/分割的字符串在創建時，則是以本地時區為基准。

那么為什么js會對不同分割的時間字符串進行不同處理呢？貌似是因為-分隔且具有前導0的日期字符串，會被解析成ISO格式的字符串，以GMT時區為基准，不過我也沒看懂。

解決

最終，既然-分割的字符串會出問題，那我就講所有的-都換成/就好了，正好也可以借此解決IOS的兼容問題。

動手解決：

/**
 * 將時間字符串轉換成date對象
 * @param dateStr
 * 時間字符串
 */
function getDate(dateStr){
    /* 若日期是使用-分割的，全部轉換成/
            因為只有日期時，js會將-分割的字符串基准時區設置為GMT，與當前時區相差8小時 */
    dateStr = dateStr.replace(/-/g, '/');
    return new Date(dateStr);
}