国际化测试中的多时区测试

产品做国际化后，需要做国际化相关的测试，如果产品功能中涉及到时间，在国际化过程中会涉及到多时区的改造和相关测试。

一、理解下多时区和带来的问题

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.不同时区用户的数据展示是否正常，用户理解上是否有困难

......

相对多语言的测试来说，多时区复杂一些，尤其是一些跟时间强相关的产品（比如我现在正在测试的排班类产品），但是相对涉及多币种的产品测试来说，多时区也仅仅是稍微复杂一点。