資訊專欄INFORMATION COLUMN
摘要：用戶場景國際版中各個倉庫分屬不同的城市，不同的城市所在時區不同，基于各個角色對數據的使用情況不一樣主要的用戶場景庫內作業人員，倉庫是紐約倉，時區是，查詢到的倉庫入庫單。在查詢結果顯示的時候，時間數據也需要轉換到紐約時區。
用戶場景
國際版中各個倉庫分屬不同的城市，不同的城市所在時區不同，基于各個角色對數據的使用情況不一樣
主要的用戶場景
庫內作業人員，倉庫是紐約倉，時區是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 |
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/70903.html
摘要：用戶場景國際版中各個倉庫分屬不同的城市，不同的城市所在時區不同，基于各個角色對數據的使用情況不一樣主要的用戶場景庫內作業人員，倉庫是紐約倉，時區是，查詢到的倉庫入庫單。在查詢結果顯示的時候，時間數據也需要轉換到紐約時區。 用戶場景 國際版中各個倉庫分屬不同的城市，不同的城市所在時區不同，基于各個角色對數據的使用情況不一樣主要的用戶場景庫內作業人員，倉庫是紐約倉，時區是UTC-05:00...
摘要：為什么選擇阿里云服務器穩定阿里云服務器云盤數據可靠性不低于，如果發生服務器宕機自動遷移，災難恢復阿里云提供異地雙活和兩地三中心的災備解決方案，當一處系統因意外如火災地震等停止工作時，整個應用系統可切換到另一處，繼續對外提供服務。為什么選擇阿里云服務器？ 1、穩定 阿里云服務器云盤數據可靠性不低于99.99%，如果發生服務器宕機自動遷移，災難恢復：阿里云提供異地雙活和兩地三中心的災備解決方案，...
摘要：年月日，亞馬遜旗下公司，宣布亞太香港區域正式開放。這個全新的區域將有助于進一步推動香港成為領先世界的創新科技城市。在香港開設全新的區域，能為我們的工程團隊減少延遲，有助于我們加快實驗，為旅客帶來全新工具，最終提升客戶體驗。新的AWS亞太（香港）區域將擴充AWS全球足跡，讓客戶在香港數據中心運行其應用程序，存儲業務內容，同時連接AWS全球網絡。香港特別行政區政府對此表示歡迎，引證香港對大型云基...
摘要：截至年月，全國已有個省區市發布了人工智能規劃，其中個制定了具體的產業規模發展目標。年我國企業相繼發布人工智能芯片。五大數據發展情況在促進大數據發展行動綱要等政策的指 showImg(http://upload-images.jianshu.io/upload_images/13825820-5b1886a2a4a6c96f.jpg?imageMogr2/auto-orient/stri...
摘要：本期大綱隨著從到千萬用戶的業務增長，通過的不同服務輕松地實現高性能和高可用的基礎架構。方坤老師本次的主題比較偏向實踐的基礎部分，假設了一個應用從小型到中型和大型的時候，可能需要用到的服務，以及相關介紹和實踐建議。 極牛技術實踐分享活動 極牛技術實踐分享系列活動是極牛聯合頂級VC、技術專家，為企業、技術人提供的一種系統的線上技術分享活動。每期不同的技術主題，和行業專家深度探討，專注...
閱讀 1387·2021-09-22 10:02
閱讀 1894·2021-09-08 09:35
閱讀 4057·2021-08-12 13:29
閱讀 2603·2019-08-30 15:55
閱讀 2263·2019-08-30 15:53
閱讀 2299·2019-08-29 17:13
閱讀 2759·2019-08-29 16:31
閱讀 2952·2019-08-29 12:24
