微信运动排行榜中某些好友的步数为何是昨天的？@数据时间属性

微信运动作为微信平台的小程序，实现原理很简单，从一个采集步数的设备获取数据然后在你好友圈(开启微信运行的好友)里进行当天排名呈现，默认是从本机获取数据(可配置)。

微信运动具有它的社交属性，利用用户的攀比心理，越来越多的人注重运动步数。使用过程中发现有时候会看到有些好友的步数是昨天的，这是为何呢？让我想到了步数的时间属性，怎么判断是当天的步数？当天数据又是怎么划分的呢？欢迎大家来到测试有话说第一季第二集，让我们聊聊数据的时间属性。

某些好友的运动步数为何是昨天的？

以9.1号早上7点的步数排行为例，第一名在中国(东8区)，第二名在英国(零时区)，比如中国是9.1号上午7点，则英国是8.31号晚上23点。

微信运动排行榜中某些好友的步数为何是昨天的？@数据时间属性

第一名的步数是9.1号的。

第一名9.1号步数

第二名的步数是8.31号的(步数和排行榜中的不一致的原因不清楚)。

第二名8.31号步数

是不是很奇怪，为何会造成这个现象呢？(可能平常大家只关注步数，却很少关注其他用户步数是哪一天的)。我就想到怎么判断是当天的步数？当天数据又是怎么划分的呢？运动步数的消息结构来解答这些问题。

运动步数的消息结构

微信运动步数来源于哪里呢？看下微信小程序中你的设置。

微信运动数据来源

默认设置来自本机，当然可以设置为其他数据来源，只要开启蓝牙功能即可。

微信运动排行榜中某些好友的步数为何是昨天的？@数据时间属性

微信运动的数据结构长什么样子呢？从网上查了下，步数的两个参数为"timestamp": 1567292400 和 "step": 100，前者是是时间戳以秒为单位，后者是该时间点的步数。

从时间戳中我们可以得到什么信息呢？先看下时间戳的定义。

时间戳是指格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起到现在的总秒数。

时间戳为1567292400，如果在中国(东8区)则为2019-09-01 07:00:00。但如果在英国(零时区)则时间为2019-08-31 23:00:00，那么时间戳是多少呢？下面的命令告诉你答案

在零时区东Linux服务器上执行

$ date -d '2019-08-31 23:00:00' +"%s"

1567263600

在东8区的Linux服务器上执行

$ date -d @1567292400

2019年 09月 01日 星期天 07:00:00 CST

相信在介绍完时间戳的概念后，相信你已经知道了时间戳中只能获取到时间但包含时区信息，上边的例子可知，一个时间戳在不同时区的时间是不一样的。如果从不同时区采集的步数却在相同服务器(也就是时区一样)上处理然后进行排行，比如中国北京时间晚上23点进行排名冠军赛，此时英国下午15点，也就是说中国步数是某种意义上当天的，英国步数实际上从昨天16点到今天下午15点这段时间内的数据。

举例：微信运动在中国的时间戳为9.1号0点到9.1晚上23点，如果时间戳都一样的话，那么其他时区的步数可能就不是9.1号当天的步数。

如果是要优化的话，建议在处理带有时间属性的数据时，要带有时区的信息，一个时间戳搞不定的。

同类的应用场景

1) 新闻联播大家都在看吧，播报员在报到国际信息时会这么说：北京时间xxx，英国当地时间yyy，在英国发生什么大事。那么英国的新闻播报员怎么播报这个新闻呢？那就是British local time yyy, Beijing time xxx, what happened at China.

中国播报员和英国播报员都做了时间戳+时区的转换，这样听众才知道事件的发生时间点。

2) 告警模块中，告警管理者在东8区，告警代理分别在东3区和东5区，浏览器客户端有可能在东8区/3区/5区登录，也有可能在其他区登录。

如果东3区和东5区的告警代理将告警上报给东8区的告警管理，如果仅仅一个时间戳(在零时区看时间是一样的)，对于东8区的告警管理来说转换后的时间是不一样的，如果能带上时区，转换后的时间是一样的。这里有个意思的问题，告警界面上呈现的时间应该是什么样的？想想新闻播报员：北京时间xxx，在英国发生某件大事。那么告警界面的告警发生时间应该呈现浏览器所在Windows主机相应时区的时间，换一个时区的浏览器查看，告警发生时间肯定不一样。

3) 安全模块中，比如要记录用户登录的时间点，那么所呈现的原理和告警是一样的。

4) 性能模块中，比如每个时区的用户，创建的性能任务的开始时间和结束时间，来自于创建任务时所登录的windows主机，任务创建的开始时间和结束时间到服务端后，服务端看到的时间也是和告警界面转换后是同样的道理。