在跨境电商的项目中，有一些活动是一个时间片，这个活动结束了，另外一个活动又起来了，是一个连续的时间片。今天因为一个上新的问题，和小伙伴有了一些争议，正好解释一下这个问题。需求是这样的，就是，每一天，定时，都会有上新的产品出现，我们的业务要求是，用户进入到这个界面时，有几个过虑的条件，
- 七天内的上新商品
- 今天的上新商品
- 昨天的上新商品
而服务器，那边记录的时间是utc的标准时间，怪在的是，服务器给我们前端的数据非时间戳，而是一个字符串，如：
2017-02-27
2017-02-26
2017-02-25
（假如今天是26号ps----UTC时间）
而我们这边如果说，想要查询到今天内上线的商品，此时，服务器接受查询的参数又是时间戳，有的同学肯定会想，那很容易啊，把
25号 00:00:01的时间当前是起启时间，把 23：59：59当前结束时间，把他们两个转化成对应的时间戳不就可以了？理面上来说确实如此，怪就怪在手机端这边有个时间区所在的时区不同，最后的转化结果，也是不一样的。
很简单：如果没有平衡统一到服务器的时间来讲的话，对于同时转化时间
2017-02-26 00：00：01 这个时间，我们来做一下测试：
在线转化工具，生成的时间：
看起来，好像没有什么毛病，这不是正常的么？细想一下，服务器那边返回的时间，可不是你北京时区的啊？
所以，如果你想查的是服务器上面的2-27号的数据？不好意思，先转化到UTC时间，其实，utc时间，与gtm的时间标准相差特别小。
GMT:
UTC:
但是呢，明显和系统默认的时区生成的时间不一样。那，如果是用了系统默认的时区来转化得到的时间戳去查询，那么，有可能查询到的数据，并非原有业务要求的数据。会相差于前后的时间落差12个小时。与你的所在的时区。
可能产生的问题：
如客户端向服务器发起请求时，服务器返回的是今天是 2016-02-26 ，而实际上，在2016-02-26 8：00：00 2016-02-26 10：00：00 上新一一批商品10，之后运营变没有更新过新的东西，而在此时，访问的时间是 2016-02-26 14：00：00 ，而如果不考虑手机端上面的时间区来说而直接进行转化，假如，你又刚好在东十一区，早于服务器的11个小时，那么，你虽说起始时间查询的是 2016-02-26 00：00：00 而转化后的时间早于系统的时间 就是他们的时区差。我们测试一下。
发现，如果同样的对0227进行时间比对，那么发现，其实相差了八个小时，假如说，时区早相差了 11个小时呢？会出现什么问题？
哈哈，那也就是说，今天没有上商品？然而是这样的么？服务器告诉我说，今天有商品，而我拿着没有同步时区的时间去问服务器要数据，服务器却告诉我没有？哈哈，当然好玩了。结果就是用户蒙逼。这种问题，出现的最多的情况是什么呢，就是一个活动，可能涉及到了多个国家的用户在体验的时候，会出现得比较奇怪，虽说是不是特别重要的一个小事情，但感觉还是分析一下的。
建议：
在这种时间的维度下，一定要与服务器的时间为准，不要相信客户端的时间。不然，总是出现很奇葩的问题。小伙伴很自信，不给解释机会，害得我都怀疑人生了。写下此文章，当成是一个笔记。平心.........
