國際版多時區設計方案

用戶場景

國際版中各個倉庫分屬不一樣的城市，不一樣的城市所在時區不一樣，基於各個角色對數據的使用狀況不同
主要的用戶場景
庫內做業人員，倉庫是紐約倉，時區是UTC-05:00，查詢2017-12-1到2017-12-10的倉庫入庫單。即查詢的是2017-12-1 00:00:00-05:00 到 2017-12-10 23:59:59-05:00 時間區間內建立的入庫單。在查詢結果顯示的時候，時間數據也須要轉換到紐約時區。
上游系統，好比OMS的系統調用。客戶擁有兩個倉庫，分別在不一樣的城市。比較典型的是下單時間。下單時間由客戶的ERP系統建立，對於不一樣倉庫的訂單，在各自的倉庫內展示時，是按倉庫所在城市來顯示。
跨倉庫的報表。勾選多個倉庫，執行查詢時，展現的時間，還是以各自倉庫所在城市時區展現。
操做倉庫無關的資源。好比域內的用戶資源。好比域管理員新建用戶帳戶，同時要設置該用戶的有效時間爲2018-11-10 ~2018-11.15日，這個是依據客戶端時區設置的。

設計方案

爲了更好的討論問題，對幾個時區作下約定：

簡稱	說明
localtime，localzone	表示客戶端時間和時區
whtime，whzone	表示倉庫時間和時區
apptime，appzone	表示應用服務器的時間和時區
dbtime，dbzone	表示數據庫的時間和時區
3rdtime，3rdzone	表示第三方系統的時間和時區，如GOMS或ERP

按照以上的場景介紹，localzone只有在操做域資源的時候會涉及。在操做倉庫資源的時候，均使用whzone。

appzone和dbzone均會設置成UTC+00:00，由於timestamp存儲範圍的緣由，故不考慮。全部時間數據均保存爲datatime。3rdzone則依賴實際狀況，可能和appzone相同，也可能不一樣。
第一種方案是全部的時間均轉化爲UTC+0的時間再保存。第二種方案比較取巧，在保存的時候就考慮以後的顯示，好比在紐約倉庫的操做是2017-12-26 15:00:00-05:00 這個絕對時間發生的，保存的時候保存爲2017-12-26 15:00:00-00:00，因此在保存的時候會有2017-12-26 15:00:00-05:00~2017-12-26 15:00:00-00:00的轉化操做。

場景	方案1（記錄UTC0時間)	方案2（記錄倉庫時間）
訂單建立時間	後臺生成系統時間（appzone）	1.得到應用服務器當前時間（apptime：2017-12-26 15:00:00+00:00）2.得到訂單對應倉庫的時區(whzone：+08:00)3.將apptime進行時區誤差處理，得到時間2017-12-26 23:00:00+00:00
訂單下單時間(3rdzone=appzone)	不須要轉化	1.得到訂單對應倉庫的時區（orderTime: 2017-12-26 15:00:00+00:00 whzone +08:00）2.將下傳的訂單時間轉化爲倉庫本地時間(whtime:2017-12-26 23:00:00+00:00)
訂單下單時間(3rdzone!=appzone)	將上游系統時區轉化到WMS時區(appzone)	1.將上游系統時區轉化到WMS時區(orderTime: 2017-12-26 15:00:00+08:00 3rdzone: +08:00 appzone:+00:00)2.得到訂單對應倉庫的時區（whzone： -05:00）3.將下傳的訂單時間轉化爲倉庫本地時間(whtime：2017-12-26 2:00:00+00:00)
倉庫操做，查詢條件中有時間	1.將查詢時間轉化爲UTC0時間(whzone->appzone)（2017-12-26 12:00:00-05:00 ->2017-12-26 17:00:00-00:00）	1.不需作轉化其實仍是須要轉化的，除非客戶上傳的是不帶時區的字符串，服務器當0時區的來處理
時間數據展現	1.將UTC0時間轉化爲倉庫時間(appzone->whzone)（2017-12-26 17:00:00-00:00->2017-12-26 12:00:00-05:00 ）	1.不須要轉化.其實仍是須要轉化的，除非服務端輸出的是不帶時區的字符串，客戶端直接顯示字符串

另外，在時間格式化的問題上，也存在兩種意見，一種是前臺處理，一種是後臺處理。若是上面採用方案2，那麼只能採用後臺處理，由於在方案2中，客戶端是不會使用倉庫時區數據的。客戶端服務端之間交互時，使用的都是不帶時區的字符串。因此在討論是前臺處理仍是後臺處理的時候，是假設上面採用了方案1.

場景	前臺處理	後臺處理
登陸時	1.後臺給前臺offsite = whzone - appzone。好比前臺的倉庫是紐約，則誤差是 -5h
倉庫操做，查詢條件中有時間	1.前臺將查詢條件依據offsite處理成long。2.後臺用long生成Date對象	1.前臺上傳時間字符串2.後臺獲取倉庫的時區信息3.轉化爲UTC0的時間
時間數據展現	1.後臺返回long。2.前臺依據offsite，轉化爲要顯示的字符串	1.獲取倉庫的時區信息。2.轉化爲倉庫的時間字符串
優勢	1.後臺處理不涉及任什麼時候間轉換處理，均是utc0的時間。2.前臺能更好的結合多語的格式配置。3.更好利用富客戶端的計算資源。
缺點	1.客戶端須要處理whzone，localzone，以及appzone之間的轉化。在登陸的時候，會返回whzone和appzone的誤差值，客戶端須要使用該誤差值處理localzone