前言

沒錯,標題起的有點唬人，但吸引你進來了，你不妨瞭解一下。本文源於使用者反饋的在QQ瀏覽器上元件的日期與星期數無法對應的Bug,測試發現是QQ瀏覽器未正確按照ECMA標準實現Date相關的函式，本文給出了ECMA規範的定義及實際測試中的結果，分析Bug產生的原因及規避Bug的方法，最後再介紹了處理時間相關業務時需要注意的時區問題, 希望對讀者能有所幫助。

Bug描述

使用者反饋在QQ瀏覽器上，元件的日期與時間無法匹配。例如2018年11月14日為週三，元件在QQ瀏覽器上展示週二。

Bug復現環境

• 系統macOS 10.14 系統時區 杭州-中國
• QQ瀏覽器版本 Mac(4.4.119.400)(64-bit)
• Chrome瀏覽器版本 Mac 70.0.3538.77（正式版本） （64 位）

Bug產生的原因

QQ瀏覽器上

• Date.prototype.toString()
• Date.prototype.getDay()
• Date.prototype.getTimezoneOffset()
• new Date(Time String)

等函式返回的值未按ECMA標準實現，共同的問題是沒有參照系統當前時區計算返回結果。

ECMA標準定義

ECMC規範連結

15.9.5.2 Date.prototype.toString ( )

This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form.

該函式返回基於當前時區的時間字串。

ECMA規範連結

15.9.5.16 Date.prototype.getDay ( )

Let t be this time value.

If t is NaN, return NaN.

Return WeekDay(LocalTime(t)).
複製程式碼

該函式返回基於當前時區的星期數。

ECMA規範連結

15.9.5.26 Date.prototype.getTimezoneOffset ( )

Returns the difference between local time and UTC time in minutes.

Let t be this time value.

If t is NaN, return
 
 NaN.

Return (t − LocalTime(t)) / msPerMinute.
複製程式碼

該函式返回的是當前時區與0時區(格林尼治時間)的差值。

測試結果

//Chrome
new Date(1542124800000).toString() // Wed Nov 14 2018 00:00:00 GMT+0800 (中國標準時間)
new Date(1542124800000).getDay() // 3
new Date(1542124800000).getTimezoneOffset() // -480

//QQ
new Date(1542124800000).toString() // Tue Nov 13 2018 16:00:00 GMT+0000 (UTC)
new Date(1542124800000).getDay()  // 2
new Date(1542124800000).getTimezoneOffset()  // 0
new Date("2018/11/14") //Wed Nov 14 2018 00:00:00 GMT+0000 (UTC)
複製程式碼

類似的問題還有

//Chrome 
new Date("2018/11/14") // Wed Nov 14 2018 00:00:00 GMT+0800 (中國標準時間)
new Date("2018/11/14").getTime() // 1542124800000

//QQ
new Date("2018/11/14") //Wed Nov 14 2018 00:00:00 GMT+0000 (UTC)
new Date("2018/11/14").getTime() // 1542153600000
複製程式碼

從以上結果來看，QQ瀏覽器的時區參考都是UTC時間(即0時區時間)，是因為獲取不到當前系統時區，而預設用了UTC時區為參考嗎？

基於以上猜想，我們再測試下Date.prototype.toLocaleString()，我們先來看下規範的定義

ECMA規範連結

15.9.5.5 Date.prototype.toLocaleString ( )

This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment’s current locale.

該函式返回基於當前時區的時間字串，展示形式需要以當前主機的語言環境而定。

可以注意到規範定義的 toString()、toLocaleString()都是以當前時區為基準，僅展現語言有差別。

測試的結果

//Chrome
new Date(1542124800000).toString() // Wed Nov 14 2018 00:00:00 GMT+0800 (中國標準時間)
new Date(1542124800000).toLocaleString() // "2018/11/14 上午12:00:00"
new Date(1542124800000).toLocaleDateString() //"2018/11/14"


//QQ
new Date(1542124800000).toString() // Tue Nov 13 2018 16:00:00 GMT+0000 (UTC)
new Date(1542124800000).toLocaleString() // "2018/11/14 上午12:00:00"
new Date(1542124800000).toLocaleDateString() //"2018/11/14"
複製程式碼

測試發現QQ是可以正確展示toLocaleXXX()的結果的，看來是能獲取到時區的嘛。

那麼基於以上測試，我們的結論是：QQ瀏覽器是能知道當前的系統時區的，但未正確實現 Date.prototype.toString()、Date.prototype.getDay()、Date.prototype.getTimezoneOffset()、new Date(Time String)等方法。

如何規避可能產生的Bug

以北京時區2018/11/14 上午12點(凌晨)的時間為例, 先展示出bug的程式碼：

日期的獲取使用toLocaleDateString()：

new Date(1542124800000).toLocaleDateString() //"2018/11/14"

複製程式碼

星期使用了getDay()

"星期" + "日一二三四五六".charAt(new Date(1542124800000).getDay()); 

// chrome中為 星期三
// QQ中為 星期二
複製程式碼

在QQ瀏覽器中，會導致星期數比正確值少一的情況。

解決的方法

知識點鋪墊

Date.now()獲取的是當前時間與格林尼治時間1970/1/1 0:0:0 的毫秒數之差, 全球所有時區的使用者，在同一物理時刻，呼叫該方法返回的數值是一致的。

假如Date.now()返回的是 1542124800000。這個毫秒數對應北京時間2018/11/14 00:00，對應格林尼治時間為2018/11/13 16:00 在瀏覽器控制檯可以進行驗證得到：

new Date(1542124800000) // Wed Nov 14 2018 00:00:00 GMT+0800 (中國標準時間)
new Date(1542124800000).toUTCString() //Tue, 13 Nov 2018 16:00:00 GMT
複製程式碼

同一個毫秒數，表示的是同一個物理時刻，體現在不同時區的時間上，會有時差。

解決思路

瞭解了這個知識點後，我們的解決思路就是統一使用Date.getUTCxxx()方法，該函式返回的以0時區為準的時間度量值。我們只需要在測量的時間上，增加8個小時的時區偏移，即可獲取到基於當前時區的時間度量值。

例如獲取星期數：

"星期" + "日一二三四五六".charAt(new Date(time + 8 * 3600 * 1000).getUTCDay()); 
複製程式碼

可能剛看到這樣的計算方式會比較繞，我們可以這麼想：北京時區比0時區快8個小時，那麼0時區8個小時候後的星期數，就是我們現在的星期數。大家可以停下來想一想。

其他注意事項

系統時區

業務場景： 倒計時

var endTime = new Date('2018/11/11 0:0:0')
console.log(endTime - Date.now())
複製程式碼

這個方法可能存在的問題是物理世界的同一時刻，不同時區使用者獲取到的Date.now()是一致的，但 new Date('2018/11/11 0:0:0')的值會根據使用者機器設定的時區而變化，所以會導致同一物理時刻，不同時區的使用者看到的倒計時時間不一致。

解決方式是建構函式傳入時區值

var endTime = new Date('2018/11/11 0:0:0 GMT+0800')
console.log(endTime - Date.now())
複製程式碼

或者 按照上述的UTC轉換法

var endTime = new Date(Date.UTC(2018,10,11,0,0,0)) - 8*3600*1000
console.log(endTime - Date.now())
複製程式碼

這樣不同時區的使用者，看到的倒計時是一致的，能在同一時間參與秒殺。

結語

業務場景中與時間相關的處理，都需要額外打一個心眼，考慮時區等因素。本文分析了QQ瀏覽器上的實現Bug，並給出了基於UTC時間轉化的方式，保證了不同時區使用者的一致性，希望能給大家帶來參考價值。