2016-04-23 251 views
2

我正在使用momentjs來檢查火車旅行的兩個時間戳之間的分鐘差異。 我使用的API以24小時制格式返回時間(momentjs:HH:mm:ss)。Moment.js 24小時時間格式,處理第24小時

如果行程繼續到第二天,則時間顯示爲例如「24:12:00」,這很奇怪。 Momentjs無法處理這個問題,如果我嘗試用這些值計算時間差異,我會得到「NaN」。

所以我創建了一個函數來將任何「24」出現轉換爲「00」。

function maintainHour (timeString) { 
    var splitted = timeString.split(':'); 
    if(splitted[0] == '24') { 
    splitted[0] = '00'; 
    } 

    return splitted[0] + ':' + splitted[1] + ':' + splitted[2]; 
} 

如果我使用diff()功能,一個時間戳,並有「00」作爲一個小時之間的時間戳檢查不同,我無法區別它是否是當天或次日內的時間戳。因此,如果當前時間是16:00(例如今天上午),而不是正X分鐘,直到即將到來的一天的24小時,那麼差異將在-900左右。

任何想法如何處理這個?

回答

2

因爲你只是在處理一段時間,所以你會遇到這樣的問題。當你處理一段時間時,時刻會假定當前分析的那一天。當然,當你將這些時間設置回零時,你會遇到你所描述的問題 - 結束時間早於開始時間。

這是不直觀的,但我可能實際上使用set的'overflow'功能來解決這個問題。

當您將某個值傳遞給時刻設定功能(.hours(),.minutes()等)時,如果該值超出允許範圍,則會溢出到下一個單位。你可以在這裏使用你的優勢。按照原樣拆分較晚的時間(可能有24個的時間)。然後做這樣的事情:

moment.utc('2016-01-01') 
.set({hours:splitted[0], minutes:splitted[1], seconds:splitted[2]}).format() 

至於發生了什麼具體的例子:

moment.utc('2016-01-01').set({hours:24, minutes:32, seconds:12}).format() 
"2016-01-02T00:32:12Z" 

正如你可以看到,24推到第二天。

這聽起來像你在這裏所有的是時間,而不是日期。如果這是正確的,那麼我強烈建議選擇一個任意日期作爲您的解析日期,並使用UTC模式作爲您的時刻。

如果您在本地模式下使用任意日期的時間,則可能會遇到由於DST轉換而導致差異不符合預期的問題。在UTC模式下,這些不會發生。

值得一提的是相反的,如果你不知道的日期,你應該使用它,並在正確的時區(與時刻時區,如果需要的話),這樣你就捕捉DST轉換可能導致差異小時在相同的兩次之間變化。

此外,手動設置日期可避免第一次調用時間落在與第二次調用時間不同的日期時可能出現的競爭狀況。這是一個稍後難以發現的錯誤。

+0

我一定會試試這個。 –