共计 1216 个字符,预计需要花费 4 分钟才能阅读完成。
JavaScript 为我们提供了不是很好用的 Date 作为时间日期对象,除了接口设计怪异之外,还有一些隐藏很深的 bug,先看接口设计:
Date() 直接返回当前时间字符串,无参数。
new Date() 则是会根据参数来返回对应的时间对象,参数很有意思:
// 无参数,并返回当前时间。
new Date();
// 可接受一个数字参数,该参数表示与 1970 年 1 月 1 日 0 点之间的毫秒数。
new Date(value);
// 可接受一个字符串参数,参数形式类似于 Date.parse() 方法。
new Date(dateString);
// 可接受年月日时分秒参数,是本地时间。
new Date(year, month[, day[, hour[, minutes[, seconds[, milliseconds]]]]]);
先且不说这样的接口未免不够灵活(很难处理各种字符串格式的时间),最诡异的一点是其中使用 dateString 的那个构造方法,MDN 网站在这个函数下有下面一段注释:
注意这里用的是 strongly discouraged – 强烈不推荐使用,原先的我没有重视这句话,直到。。。付出惨痛的代价。
现象
我的一款每日打卡类的 App,因为有大量的时间运算,为了能接受各种时间,我做了一个方便的函数:
date2ymd(input) {
let day = (input instanceof Date) ? input : new Date(input)
return `${day.getFullYear()}-${day.getMonth() + 1}-${day.getDate()}`
}
上面的函数在某些 input 时没有问题,但当参数为类似’2018-10-1’这种格式,按照 MDN 的文档,就属于强烈不推荐使用的形式,但我没有留意,App 发布之后,不错,大部分用户没有反馈问题,直到某天,一个阿根廷的用户给我邮件反馈,说界面上的日历似乎错乱了,我试着更改自己的时区到对应的 - 3 时区,截图一看:
上图中彩色小方块的区域是年视图,本来应该和下面的日历一一对应,但在这个时区下,年视图完全错位了,肯定是哪里计算错误了,经过调试,我找到了上面这个函数,并发现了问题,我们用 chrome 的 console 演示一下:
看到了吗?从 9 号到 10 号,转换出的时间没有翻天,当然,我们可以为这种转换找到理由,JS 应该是把这种参数当成 UTC 时间了,我们看看 firefox:
Firefox 的表现可以理解,因为 UTC 和 -3:00 时区之间有个时间差,虽然这依然不是我想要的,但比起 chrome 的跳变要好接受一些,我们把输入时间换一个格式,再看下在 chrome 下的例子:
这种格式终于符合了正常逻辑,也就是短杠和斜杠分隔的时间处理上是不一致的,斜杠分隔的时间终于正确的按照了本地时间进行处理。
结论
正如 MDN 所说,不要使用单字符串参数的 Date 构造函数,即使你知道各种格式之间的区别,也不建议使用,毕竟记忆这些微妙,甚至不兼容的差别毫无意义。