首页 > W3C Lab > JavaScript > 应该把 moment.js 换成 day.js 吗?
2018
05-05

应该把 moment.js 换成 day.js 吗?

TL;DR

如果在Safari中你使用 dayjs(“2018-10-10 00:00:01”)  这种非 ISO 8601 的时间格式,会得到一个 Invalid Date,而 moment 可以正常处理

WTF is Going On

我们有一个项目中使用了 moment ,因为 moment 比较大,想通过一些方法减小压缩包,我建议前端开发使用去除 moment 的 locale 的 Webpack Plugin 去尝试,但我们的前端刚好看到了 xx团公众号推荐一个号称兼容 moment 的只有 2KB 大小的 dayjs,于是他兴高采烈的用 dayjs 替换了 moment,开始一切都很正常,直到…

我使用iphone测试时,发现所有的列表中应显示的 MM/DD 格式的时间都变成了 NaN/NaN ,Holy Shit!这是为什么,由于这个项目是一个微信H5页面,我们使用Fiddler / VConsole 在本地调试并查看报错,没有任何问题,最终感觉是不是输入的日期不合法呢?

于是找到dayjs的源码,2KB的源码很少,一查就看到了实例化使用的函数实际上是 new Date(), 我一想 Date 难道不接受 2018-10-10 00:00:01 这种格式的时间吗,在 iphone 上使用 vconsole,输入 new Date(‘2018-10-10 00:00:01’), 结果显示 Date null,原来safari还有这种套路,真是想不到,这时想起之前使用的 moment,同样查看了源码,发现 moment 的源码逻辑还是相当复杂的,找到格式化时间的文件,moment 最后也是使用 new Date函数,但在这之前对时间进行了格式化处理,怪不得在推荐 dayjs 的文章下面有人回复:“一个2KB就实现了moment兼容功能的库,难道写moment的人是SB吗?”

后续在 Mac 上尝试一下发现 Safari 中结果类似,返回的是 Invalid Date,于是 Google 了一下,发现这个问题很早就有人问了,IE 好像也是不支持这种格式的,查看 ECMA 文档的 Date 节,原来Date函数接受一种 ISO 8601 的扩展格式,就是 YYYY-MM-DDTHH:mm:ss.sssZ 这种格式的子匹配,再查一下我们时间戳来源的 MySQL 文档,timestamp 的格式,嗯 MySQL 并没说它使用了什么标准,好吧,原来 MySQL 才是罪魁祸首。

结论已经很明显了,为了更广泛的兼容时间格式还想压缩打包体积?看看你的需求

最后编辑:
作者:scplay
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。