国际版多时区设计方案【转】
用户场景
国际版中各个仓库分属不同的城市，不同的城市所在时区不同，基于各个角色对数据的使用情况不一样
主要的用户场景
库内作业人员，仓库是纽约仓，时区是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 |
原文地址：https://segmentfault.com/a/1190000012611095
