我們做的的都是國際化大項目，今天發現了個大bug,沒錯！是時區不同引起的，如果你覺得這還不簡單，這樣，這樣，再這樣不就可以了嗎？我只能呵呵了。
先來普及一下基礎知識 :
1、地球分為24時區，北京位於東八區，倫敦位於零時區，東京位於東九區，北京8點時，東京9點，倫敦0點。也就是北京比倫敦早8個小時，東京比北京早1個小時。
2、時間戳：可以理解為時間間距，定義為格林威治時間1970年01月01日00時00分00秒，也就是你在倫敦當前時間戳為：從1970年01月01日00時00分00秒到現在再轉化為毫秒，如果在北京的話：從1970年01月01日08時00分00秒到現在再轉化為毫秒。但是其實是一樣的，因為間距不變啊。放張大圖自己領會。。。
案例：設備聚合數據端在倫敦，上傳到監控系統，監控系統也就是我們的項目在北京。用戶A倫敦，用戶B在東京。現在時間分為：設備端、browser端，和sever端
場景一：用戶A在2017/8/4 00:00:00（倫敦的）和用戶B 在2017/8/4 9:00:00（東京的）上線，我在北京查詢用戶A和用戶B的上線時間。
分析：其實A和B是同時上線的，無論是按照設備端，還是browser端。如果系統按照browser端時間設置，我將看到A和B在北京時間2017/8/4 08:00:00同時上線。如果系統按照設備端，我將看到A和B在倫敦時間2017/8/4 00:00:00同時上線.。。。這個比較好理解。
場景二：我在北京2017/8/4 08:00:00查詢用戶A近24小時的流量數據。
分析：同樣，我想知道的是北京時間往前推24小時的流量，那到了倫敦也同樣是倫敦時間往前推24小時，設備聚合倫敦近24小時數據量，是可以的。也就是無論安照設備端還是browser端顯示都是可以的。
場景三：我在北京2017/8/4 07:00:00查詢用戶A近1/7/30天的流量數據。（數據聚合都是在每天的零點）
分析：這樣按照前面兩種就會出現問題：北京時間8/4 07:00:00近一天的也就是8/3 00:00:00到8/4 00:00:00，那到了倫敦當前時間為8/3 23:00:00,近一天的也就是8/2 00:00:00到8/3 00:00:00，這樣的話，統計時間的開始時間和結束時間根本不對應啊。統計時間應該為倫敦軸下方的那一段。也就是放張大圖，自己領會。。。
那怎么辦呢？這樣的話，我們只能按照設備端時間查詢顯示，沒辦法啊，因為如果按照browser端的00:00:00，那設備端為16:00:00數據還沒有聚合。