2019年12月的第一个bug

现在是2019年12月1日0点27分，我的心情依旧难以平静。这个月是2019年的最后一个月，是21世纪10年代的最后一个月，也是第一批90后30岁以前的最后一个月。就是在这个月的第一天的0点0分，我写的代码出了一个bug，简直让我欲哭无泪。

事情是这样的，我们公司在双十一搞了个促销活动，时间是11月1日到12月1日0点整。为了保证在2019-12-01 0点时，所有小程序上双十一相关的UI元素准时下架，我写下了如下代码：

// 查出12月1日的时间戳
new Date('2019-12-01').getTime() //或Date.parse('2019-12-01') 1575158400000
const isS11 = Date.now() < 1575158400000

一切的UI元素都将根据这个isS11这个布尔值进行显示和隐藏。我提前把逻辑写好之后，早早就发布到线上。周五运营的同事问起时还得到我信誓旦旦的保证，我说，肯定没问题，我都安排好了，0点保证下架。

0点的钟声敲响了。老板在群里发了红包，我抢过了之后，打开小程序，看看双十一是不是下线了。意外还是出乎意料的发生了，元素还在！！我有点慌了起来，又尝试了刷新和重新打开小程序，双十一依然还在，纹丝不动。我就觉得脸有点火辣辣的——打脸了！

我马上打开vscode，查找原因，在控制台写下下面的代码：

纳尼？为什么是早上8点？？？不应该是默认0点吗？不管了，先改正再说，于是加上时分秒：

const isS11 = Date.now() < Date.parse('2019-12-01 00:00')

这回正常了。赶紧紧急提交一个版本先～提交完之后开始翻TC39的规范：终于在这里找到了解释。当Date构造函数接受一个字符串作为参数时，会调用Date.parse来得到时间戳。而在Date.parse中有这么一段话：

When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

翻译过来就是：当字符串中没有UTC的标记时，只有日期的字符串会被当成UTC时间来解析，有日期和时间的字符串会被当成本地时间来解析。

new Date('2019-12-01') //按UTC0时区的时间0点，相当于北京时间早上8点
new Date('2019-12-01 00:00') //按北京时间0点

我们是东八区，比UTC时间快8个小时。我输入的字符串是2019-12-01被当成UTC时间的12月1日0点，所以换成本地时间是12月1日8点。。。

最后，首先吐槽一下TC39制定规范的大佬们，为什么不能都按本地时间来解析呢？不然我也不会掉到坑里。。不过，好在微信加急审核效率高，只用半个小时就审核通过（这里给微信点个赞