JS 的 Date API 究竟是个什么阴间东西

Date API 你们确定都有用过，虽然更多时候关于日期的处理都交给了 dayjs 或者 moment。

但咱们确定免不了去直接使用原生 API，这时候你可能会免不了爆一句粗口「什么阴间玩意？」，接下来咱们来看看到底这个 API 很差用到哪里去。

首先咱们先了解下 Date 支持哪些类型的传参：

new Date();
new Date(value);
new Date(dateString);
new Date(year, monthIndex [, day [, hours [, minutes [, seconds [, milliseconds]]]]]);
复制代码

了解完参数类型，就直接用起来咯：

没啥毛病，符合预期，不传参就获取当前系统时间。

那么咱们换种写法，传入字符串呢？

小小的脑壳充满了问号，明明我传入一样的日期，无非格式变了一下，为啥输出的内容却彻底不同？

笔者这里解释下，当咱们输入第一种格式时，内部会帮咱们解析成当前时区所对应的协调世界时（UTC），也就是零点加八小时。

而当咱们输入第二种格式时，内部会帮咱们解析成当前时区的零点。

到这里其实笔者已经有点懵逼了，不踩过这种坑鬼知道会有这样的不一样。

你觉得这样就结束了？天真了，咱们再来看这种写法：

好家伙，我这传的明明是七月份，咋的给我解析成八月份了？？？

这看起来是个 Bug，实际上算是一个老传统，在好久以前的编程语言里确实以 0 开头做为某些时间的起始位：

以上内容你们能够在 Linux 的文档中阅读到。

文章到这里尚未结束，我们再来换个写法看看：

这第一个写法笔者还能理解一点，毕竟年份从 1900 年开始计数，可是为啥换成数组的写法你就给我变成了 2032 年啊！

笔者这里也就不考古了，反正打死不这样写就好了。

---

更新：这里读者解释是由于 [32, 10, 4] 被转换为了字符串，也就是 new Date('32, 10, 4')，所以结果如图所示。

---

那么多坑，心累了，之后就只用 new Date() 吧，但其实也很差意思，单用这个你说不定也能踩到一个坑。

举个场景，咱们在服务端给接口 setCookie 的时候都会设置一个 expires 字段表明这个 Cookie 的有效时间，此时若是你的 expires 字段是以 new Date() 生成的话，千万记得要作一次转换。

好比说咱们利用 new Date() 获取了一个时间，你们能够看到输出是带有中文的：

此时若是你把这个时间去作 setCookie 的话，服务端就会报一个 TypeError 的错误：invalid character in header content ["set-cookie"]，这是由于咱们设置的值里存在中文。

所以咱们须要对这个时间作一次转换获得一个不包含中文的时间字符串。

讲了那么多，难道原生 API 真的没救了？只能全用库了么？这倒也不是，TS39 也知道如此阴间的 API 很差用，所以搞了 proposal-temporal 这个提案来解决问题，算是融合了目前日期处理库的功能。

可是等这个提案兼容大部分浏览器也不知道何时呢，仍是继续 dayjs 吧。