什么是时区？嗯，这好像是个地理问题，为啥要讨论这个？先问你个问题，假设一个人A在中国，一个B在美国，他们使用同一个APP比如说是微信，A在微信里发一个消息给B，请问，A微信中显示的这个消息发送时间和B微信中显示的这个消息的接收时间是一样的吗？

答案是：不一定

啊？为啥？回答之前，我们先看下时区的定义吧：

时区是地球上的区域使用同一个时间，全球划分为24个时区，也就是每隔经度15°划分一个时区，24*15°=360°，嗯，没错，正好是一个球，也就是我们的地球。

嗯，这个定义没毛病，就像我们把一个西瓜分成了24份，这24份各有各的主子。但是，等等，这是个球啊，每一份都长得一模一样，主子们在外出或者干别的事儿回来后怎么知道之前分给他们的是哪个？所以，我们需要从这24份中找一个插上一个小旗子，命名为0号，然后从左开始给每一份瓜起个名，1、2、3一直到11，也从右开始给每一份瓜起个名，-1、-2、-3一直到-11，最后剩下的一个起名为+-12，就谁也不会记错了。

UTC & GMT & CST

从西瓜这个例子回到时区，插小旗的那个我们就叫他UTC（Universal Time Coordinated - 协调世界时），其他时区和它的关系如下图：

时区

UTC格式

UTC的标准格式为2019-11-11T00:00:00.000Z，其中：

• T代表使用UTC时间
• Z是UTC偏移量，表示UTC时间与本地时的差别 - 即时差。Z本身表示0时区，读作Zulu。写作Z或不写的时候，表示不偏移、即0时区的时间。需要偏移时，将Z替换为真实的偏移量。偏移量可用以下形式表示: ±[hh]:[mm]、±[hh][mm]、±[hh]

举个栗子：

• GMT时间无需偏移，写作2019-11-11T00:00:00.000。
• 北京在东8区、比GMT要早8小时，写作2019-11-11T08:00:00.000+0800

Unix时间戳

时间戳是指格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至现在的总秒数（也可以支持到毫秒）。
时间戳是一个时间流逝的总数，一直在增长，它没有时区的概念，就算有，也只是它的开始时间是格林威治时间1970年01月01日00时00分00秒这么多了。所以，无论你现在身处美国、还是欧洲、还是中国，同一时间Unix时间戳的数值都是一样的。当然，UTC也是一样的。

回答问题时间到啦！

还记得文章开始说的那个问题吗？A在微信里发一个消息给B，请问，A微信中显示的这个消息发送时间和B微信中显示的这个消息的接收时间是一样的吗？预期应该显示的是各自的本地时间才对，毕竟生活在不同的国家，使用各自的时间。

答案是不一定的原因，是因为要看系统配置和程序员是怎么写的代码：
假设抓取消息的接口返回的是Unix时间戳。我们知道Unix时间戳无论对于生活在哪里的人都是一样的，所以如果要在APP客户端上展示时间就需要将Unix时间戳转化为日期。这个转化的过程就要分两种情况了：

1. 客户端根据手机设置中的时区设置来转化
   这种情况不会产生问题的原因在于，我们就是假设用户的手机系统其实就是他针对自己所在的时区设置的。所以，程序在处理时间戳时自然就用手机系统的时区信息去进行转化（这里需要假设程序员没有在代码里写死时区，否则就会出现下面第2种的情况），就是本时区的时间。所以，在美国的B收到的消息显示的接收时间是他本地的美国时间，而非中国的A发送时的中国时间。当然，如果B的手机时区设置不是美国的，那就另当别论了。

2. 客户端根据UTC或者CST来转化
   这种情况就会产生问题，如果在客户端写死了转化时间戳到CST时间的话，那手机上永远看到的时间就是中国时间。就算手机系统的时区再怎么变化，APP内的时间也是中国时间。这样就会产生不同时区却都展示一个时间的BUG。当然，除非有业务的特殊需要。

测试人需关注

对于测试来说，我们要去了解程序员处理时间的代码是不是根据系统时区来自动转化的，大部分业务下这样是最合理的；同样的，我们也需要知道系统现在的时区设置是什么，因为它也反过来影响接口返回的时间。我相信大家都遇到过由于数据库或服务所在的服务器或docker的时区不是CST而出现时差不对的情况吧