以前一直在国内的互联网公司,时区问题看上去一个从来不用去考虑的问题. 但是在面向全球的产品中,这个问题又是不得不考虑的,最近连续遇到了两个线上的 bug 都是时区相关的,现在就简单说一下.
- 会议的结束时间早于开始时间
我们产品的一个业务就是分析用户在上班时的行为习惯,提出针对性的建议和意见.所以其中一个部分就是需要记录下用户的会议起始结束时间,然后判断用户的工作中会议占比多少.一切都非常的顺利,直到突然有一段时间,大量的线上 bug 出现, 表现出来的症状就是Search Key Not Found. 这边简单交代一下我们的业务场景, 我们会对用户的每个会议进行分析,然后按照当天的日期进行记录.但是业务逻辑中有一段是要检验输入参数的,当会议开始时间晚于会议结束时间时,则会抛出异常.我们根据异常日志也定位到了这里,结果百思不得其解,其中有一点是这是一个以色列用户在欧洲某数据中心时出现的异常,也造成了我们 debug 的时候的一些困难.
最后的原因也很简单, 就是冬夏令时的原因. 关于冬夏令时这个部分可以在歐洲夏令時这里了解到. 因为之前都是在开发国内软件, 不用考虑时区问题, 也算是吃了亏涨了经验.
- IOS 提交的时区信息无法被 C# 正确解析
这个问题就更加好玩了. 我们有个业务需要记录用户的时区信息, 正常情况我们当然使用 C# 中的 System.TimeZoneInfo class 来进行记录和序列化, 目前系统也是这么运行的. 但是后来我们要上一个新 feature, 合作的 IOS Team 提出了个问题, 时区要用什么格式进行存储. 当时我们一头雾水, 为什么这个还要进行讨论, 深入了解下来, 原来时区也是有门道的.
简单的说, 目前并没有一个统一的, 或者说所有语言都支持的时区分类. 对于 Windows 系统而言, 能够识别的时区信息都存储在注册表里 \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones, 如果你用注册表编辑器, 就可以看到当前系统支持的时区. 这个版本的时区信息我们先简称为 Windows 时区信息. 因为我们的系统都跑在 Windows Server 上, 统一使用 C# 进行编程, 所以并没有出现什么问题. 但是 IOS 则是支持的另一套标准, 关于这个可以参考 时区信息数据库.
问题就来了, 后者 CLDR 看似是一个标准的通用的存储方式, 当时和我们的现有系统无法结合, 这就涉及到了迁移的问题,目前这个还在讨论中. 本来以为是 IOS 是异类, 结果到头来发现原来是微软倒行逆施, 特立独行…
以上就是最近遇到的两个时区方面的问题,也是比较忙,博客都很久没有更新了.希望以后有空多写写吧.