我司業務分布在跨時區的多個國家，我在日常積累了較多的時區處理經驗，在此分享一下

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

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

timestamp，這是unix時間戳，從1970-1-1開始的秒數，之前為負數。全球統一，無時區。如1495079384

時間戳和時間的相互關系

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

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

數據統計的影響

時區對數據影響是很大的，尤其涉及到數據分析時，需要小心處理時區。各種數據庫都有相應的轉換方法

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

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

服務器api處理

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

如果一定要用時間來傳參和入庫，建議統一用utc

瀏覽器javascript的處理

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

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

轉載于:https://www.cnblogs.com/elsonwe/p/6874135.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。