产品做国际化后，需要做国际化相关的测试，如果产品功能中涉及到时间，在国际化过程中会涉及到多时区的改造和相关测试。
一、理解下多时区和带来的问题
Los Angeles的23:00 等于 Manila的第二天的14:00
带来的问题：
问题1：展示数据的时候，是展示14:00还是23:00?
问题2：写入数据的时候，是写入14:00还是23:00？
二、多时区的质量和业务风险？
理想的、最简单的场景：
1.DB存储的时候尽量用时间的绝对值（timestamp类型）
时间戳 指的就是Unix时间戳(Unix timestamp)。它也被称为Unix时间(Unix time)、POSIX时间(POSIX time)，是一种时间表示方式，定义为从格林威治时间1970年01月01日00时00分00秒起至现在的总秒数。
页面展示的时候需要将DB中timestamp转换成页面展示时间（时间字面值+时区）
页面数据写入的时候需要将（时间字面值+时区）转换为DB数据（timestamp类型）
2.站点的使用者用同一个时区
实际上：
1.DB中大量使用Varchar类型或者其他类型存储时间，存储时丢失了时区信息
下图示例中是一个真实的业务数据表，workset_date使用的是date，start_time/end_time用的是varchar(32)
2.创建和使用数据的用户时区不一致
3.同一个数据不同使用者的时区不一致
4.不同时区的时间数据聚合计算不知道以哪个时区为基线
......
三、多时区的核心测试点？
1.支持多时区后，历史数据的展示是否正常、兼容性是否有问题
2.DB中时间在页面读写的转换是否会出现时间精度的丢失
3.不同时区用户的数据展示是否正常，用户理解上是否有困难
......
相对多语言的测试来说，多时区复杂一些，尤其是一些跟时间强相关的产品（比如我现在正在测试的排班类产品），但是相对涉及多币种的产品测试来说，多时区也仅仅是稍微复杂一点。
网友评论