随着越来越多的APP涉及境外业务，很多时候需要考虑到时差场景。那么作为一个有想法的测试员来说，怎么去理解时差，从什么角度去测试？另外针对夏令时怎样做校验？怎样监控时差的准确性？这都是今天要分享的知识点哦。
什么是时区，时差从何而来？
首先，时区是地球上的某一区域使用同一个时间定义。以前，人们通过观察太阳的位置（时角）判断时间，这就使得不同经度的地方的时间有所不同（地方时）。时区通过设立一个区域的标准时间部分地解决了这个问题。
世界各个国家位于地球不同位置上，因此不同国家的日出、日落时间必定有所偏差。这些偏差就是所谓的时差。
理论时区以被15整除的子午线为中心，向东西两侧延伸7.5度，即每15°划分一个时区，这是理论时区。理论时区的时间採用其中央经线（或标准经线）的地方时。所以每差一个时区，区时相差一个小时，相差多少个时区，就相差多少个小时。东边的时区比西边的时区时间来得早。
为了避免日期的紊乱，提出国际日期变更线的概念。但是，为了避开国界线，有的时区的形状并不规则，而且比较大的国家以国家内部行政分界线为时区界线，这是实际时区，即法定时区。比如中国，从最东面的黑龙江省（东经134°46′）到最西面的（东经73°33′），总共51°13′，所以共跨越5个时区，但法定时区只有一个，即常见的北京时间，东八区。
APP上处理时差的方式
据目前了解，市场上各个应用处理时区大致有两种方式。
其中一种是取系统的时区。我们不妨打开手机，到系统设置中的时间设置看下，在此处时间和时区可以系统自动设置，也可以我们自定义，很多APP的时区和时间也是根据该处的设置而计算的。比如说iPhone自带的时钟（假如你用的是iphone手机）应用，当你把时区调到洛杉矶，时间为5月18号2:00时，该时间就成了在洛杉矶的时间2:00，此时去看北京时间，北京的时间为17:00，这个时间就是系统设置的时间2:00加上两个城市法定时区的间隔15个小时成为了17:00。APP使用该时区和时间的方法，比较简单，但是会存在一些问题，如果当用户误设置了时区，或者时间校验不准时，就会导致用户查询到跟时间有关的信息不准确，从而影响用户的使用。
举个栗子。当作为老板的你正在纽约出差，有一超过N多个亿美元的合同要需要你紧急飞往洛杉矶签合同，或者要飞拉斯维加斯跟比尔盖茨商量下收购Google的事情，此时你得赶紧得让秘书订机票，此时在国内得秘书赶紧拿起手机，马上在一款APP上按照所谓的“今天”，预定了最近的一个航班，你拿到预定成功的消息后，风尘仆仆的赶到了机场，准备安检，心里盘算着此笔业务做成后能够统一全球科技市场，引领一场技术风暴等等，安检人员默默扫了你一眼告诉你：先生，你的飞机将会在15个小时后起飞。我们可以想象得到你内心的崩溃，然而也无能无力，毕竟是N多亿的生意就这么泡汤了。当然，这个只是玩笑，但也说明了准确的时区对于用户的价值。
还有一种方案是APP会根据自身服务的时间，自动计算时区。这种模式下，不管手机时间和时区如何设置，APP上只根据查询的城市或所在的位置，自动计算用户的时区。该方法需要处理两种查询方式，第一种是按照某一城市查询，另外一种是按照当前用户的地理位置查询。首先介绍下按照城市查询的设计支撑，APP端根据所支持的城市列表，批量调用Google接口取到城市所在的法定时区和是否支持夏令时，通过接口方式下发给APP，APP根据服务器时间和所下发的时区信息计算出当前当地时间（LocalTime），作为城市的当地时间。在这种模式下，即使手机的系统时间设置错误或时区未调整也不会影响查询结果。当APP按照当前位置时，APP上传经纬度和所在地的坐标体系（国内高德或者百度，海外Google），服务端接收到数据后查询地图平台的时差信息，回传信息到APP。APP拿到结果后，结合服务端时间计算当前位置的时间。此种方式也可极大程度规避信息不准确。
从哪些角度查询时差？
时区分为城市时区和用户当前位置的时区，城市时区即城市所在国家的法定时区，如中国即便横跨5个时区，但法定时区只有一个东八区。用户当前位置的时区，是指当用户打开定位时，系统根据用户的位置，解析出用户所在城市，然后逆查得到时区。
怎样测试时差的准确性？
假定以北京时间来校验时差，即以东八区时间为准，分为下面两种场景：
一种是查询城市的时间比北京时间早，如当查询城市所在地时间是5月12号13点，城市时间比北京时间早一个小时，那么北京时间就是5月12号12点，如东京等，首先要确定APP上的时差是否准确，这个可以拿取到的时间和时间网或者地图时差接口作对比。另外直观的角度上看，时差会影响当地时间的“今天”具体是哪天，如当北京时间的“今天”是5月12号23:30，那么东京的“今天”就是5月13号00:30。
另外一种是查询城市的时间比北京时间晚，如当城市所在地时间是5月12号11点，城市时间比北京时间晚一个小时，那么北京时间就是5月12号12点，如曼谷，新加坡等。测试时除了要查看APP时间外，同样需要注意日期跨度问题，此时北京时间迈入后一天的日期，而城市的日期仍在前一天，如当北京时间的“今天”是5月13号00:30时，曼谷或新加坡等的“今天”则是5月12号23:30。
在测试时，需要特别注意日期跨度问题，“今天”的一早一晚，开发在处理时容易遗漏的场景。建议作为有特别风险的场景，重点关注。
时差监控方案如何实施？
为了监控系统中的时差准确性，曾经尝试过不同的方法，也走过许多弯路，比如选取TopN的城市，每天自动跑脚本校验；取不同的经纬度，采用模拟定位方法，校验时差等。经过脚本的时断时续和解决方案的各种变动后，终于被我们智慧的小伙伴想出来一条最为有效的方法（别问为什么，至少我认为是），这也是运行一年来，发现问题最多的监控方案。方法如下：
每天随机从用户访问日志上，取到部分用户所查询的城市或者用户的经纬度，（仅可以拿到用户的访问日志，不涉及用户隐私），模拟用户请求，取到系统返回的时差，同调用地图开放的时差接口对比，如果两者有差别，查明差别的原因，理由适当时作出时区修改。由于该监控随机挑选城市和位置，每次检测的地区和国家范围不固定，长时间监控可以涵盖到世界范围内的多个国家和城市，能够保证大部分地区的时区准确性。
时差监控和测试中遇到的一些问题分享
监控出来的问题有许多，比较常见的是城市维护了错误的时差，比如，洛杉矶的时差维护成其他城市时差；另外比较常见的是当夏令时启用时，APP系统未及时更新时差，导致时差相差一个小时；当然当两个城市处于同一经度上，但属于不同国家的城市，系统可能只判断经纬度所在时区，未考虑法定时区，也会导致计算错误等。以上这些问题是经过长久监控出的问题，希望大家在以后的测试过程中，以作参考。