关于中国的夏令时转换

做为90后的我一直觉得中国是没有夏令时的概念的，直到上次项目中碰到一个问题。

问题是这样的，客户在管理后台录入一我的员的生日是1989-05-23但是到ios上发现日期是1989-05-22。由于先后端使用的时间戳来传递时间的，在ios上格式化为YYYY-MM-DD HH:mm:ss以后打印发现是1989-05-22 23:00:00。而在android和chrome上打印的都是1989-05-23 00:00:00。足足少了一个小时。

在中国的话通常时间上少8小时，那么多是国际标准时间和北京时间的时差致使的，一个小时却是不多见。不过以前作过一个国际的项目，针对欧美那边的用户有个叫夏令时冬令时的差异，这个刚好是有一小时的先后调整。会不会是夏令时致使的呢？

因而在chrome和safari上试了一下：

// chrome
new Date(1989, 4, 23) // Tue May 23 1989 00:00:00 GMT+0900 (中国夏令时间)

// safari
new Date(1989, 4, 23) // Tue May 23 1989 00:00:00 GMT+0800 (CST) = $6

复制代码

咱们能够看到chrome自动针对当地时区作了夏令时转换，后面的时区是GMT+0900，而safari是GMT+0800。

查了一下，原来中国在86年-92年实行了一段时间的夏令时：

1986年4月，中国中央有关部门发出“在全国范围内实行夏时制的通知”，具体做法是：每一年从四月中旬第一个星期日的凌晨2时整（北京时间），将时钟拨快一小时，即将表针由2时拨至3时，夏令时开始；到九月中旬第一个星期日的凌晨2时整（北京夏令时），再将时钟拨回一小时，即将表针由2时拨至1时，夏令时结束。从1986年到1991年的六个年度，除1986年因是实行夏时制的第一年，从5月4日开始到9月14日结束外，其它年份均按规定的时段施行。在夏令时开始和结束前几天，新闻媒体均刊登有关部门的通告。1992年起，夏令时暂停实行。

所以在chrome中转换为时间戳的时候，自己就少了一个小时的时间。

// chrome
new Date(1989, 4, 23).getTime() // 611852400000

// safari
new Date(611852400000) // Mon May 22 1989 23:00:00 GMT+0800 (CST) = $7

复制代码

这时候咱们在消费这个时间戳的时候就很差判断原有的时间是什么了。仅仅针对生日这种特殊状况来处理的话，由于上传的时间确定是某日的零点的时间，所以，检测是23点的时候，咱们能够加一个小时，可是除了这种特殊状况咱们就很差处理了。

想要根治这种问题，咱们就须要在生产这个时间戳的时候就要针对夏令时作处理。好比说检测new Date().toString()中是否包含夏令时或者+0900这样的字符串。若是有则说明进行了夏令时转换。这时候咱们的时间戳就须要在原有的基础上加上1h的时间。或者使用momentjs的检测是否进行夏令时转换函数判断也能够。