我司業(yè)務(wù)分布在跨時區(qū)的多個國家，我在日常積累了較多的時區(qū)處理經(jīng)驗，在此分享一下

首先基本概念，時間分為2種

datetime，這是給人讀的時間，分時區(qū)。如2000-1-1 12:00:00 gmt

timestamp，這是unix時間戳，從1970-1-1開始的秒數(shù)，之前為負數(shù)。全球統(tǒng)一，無時區(qū)。如1495079384

時間戳和時間的相互關(guān)系

全球時間戳是一樣的，比如1495079384在哪里都是這個值，只不過它在北京時區(qū)是2017/5/18 11:49:44，而在莫斯科時區(qū)卻是2017/5/18 06:49:44

時間和時間戳可以相互轉(zhuǎn)化，都依賴時區(qū)。比如上面莫斯科在utc+3而北京在utc+8，所以莫斯科比北京慢5個小時

數(shù)據(jù)統(tǒng)計的影響

時區(qū)對數(shù)據(jù)影響是很大的，尤其涉及到數(shù)據(jù)分析時，需要小心處理時區(qū)。各種數(shù)據(jù)庫都有相應(yīng)的轉(zhuǎn)換方法

舉個例子。比如收入表，入庫時間字段timer是utc時間(如：2015-1-1 12:15:11)，而你要統(tǒng)計莫斯科2015-1-2的一天的收入。那么直接where timer between '2015-1-2' and '2015-1-3'所得到的結(jié)果，是有問題。因為莫斯科比utc快3個小時，所以這個結(jié)果實際統(tǒng)計的是莫斯科1-2日3點開始到1-3日3點結(jié)束的時間短，結(jié)果比真實數(shù)據(jù)少了3小時當天，并多了3小時第二天的。

正確的做法，是在where里將timer轉(zhuǎn)為莫斯科時間，如 where timer at time zone 'utc+3' between ... and ... (in postgre sql)

服務(wù)器api處理

個人建議，api里所有時間參數(shù)，統(tǒng)一用timestamp，可以毫秒也可以秒。這樣不用考慮時區(qū)，適合全球化部署。而且時間戳比時間，在格式上更容易處理

如果一定要用時間來傳參和入庫，建議統(tǒng)一用utc

瀏覽器javascript的處理

所有form input組件，無論h5原生的input type=datetime-local還是datepicker，時間就是字面量。比如輸入了2000-1-1 10:00，拿這個value就是這個本身，沒有時區(qū)

用new Date來生成時間戳，如new Date('2000-1-1 10:00').getTime() ?這個結(jié)果跟你打開瀏覽器的時區(qū)有關(guān)。不同的時區(qū)，執(zhí)行結(jié)果是不同的。跟服務(wù)器位置無關(guān)，因為js是客戶端執(zhí)行

轉(zhuǎn)載于:https://www.cnblogs.com/elsonwe/p/6874135.html

總結(jié)

以上是生活随笔為你收集整理的时区处理总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。