我们做的的都是国际化大项目，今天发现了个大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数据还没有聚合。