摘要：用户场景国际版中各个仓库分属不同的城市，不同的城市所在时区不同，基于各个角色对数据的使用情况不一样主要的用户场景库内作业人员，仓库是纽约仓，时区是，查询到的仓库入库单。在查询结果显示的时候，时间数据也需要转换到纽约时区。
用户场景
国际版中各个仓库分属不同的城市，不同的城市所在时区不同，基于各个角色对数据的使用情况不一样
主要的用户场景
库内作业人员，仓库是纽约仓，时区是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://www.ucloud.cn/yun/90470.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、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。每期不同的技术主题，和行业专家深度探讨，专注...
阅读 1714·2021-10-18 13:30
阅读 2567·2021-10-09 10:02
阅读 2939·2021-09-28 09:35
阅读 2074·2019-08-26 13:39
阅读 3506·2019-08-26 13:36
阅读 1936·2019-08-26 11:46
阅读 1089·2019-08-23 14:56
阅读 1674·2019-08-23 10:38
