脚本宝典收集整理的这篇文章主要介绍了

JavaScript Date.parse 的小坑

脚本宝典小编觉得挺不错的,现在分享给大家,也给大家做个参考,希望能帮助你少写一行代码,多一份安全和惬意。

TL;DR

new DateDate.parse 在格式化某些日期字符串的时候,时区具有不确定性,最好用 moment.js 这类工具去处理。

不确定的日期字符串

事情的起源是客户跟我说网页上的某个日期总是比实际日期少一天。经过一步步 debug 后发现问题在此:

// 客户时区为美国东部时区夏令时
new Date("2015-03-31")    // Mon Mar 30 2015 20:00:00 GMT-0400 (EDT)

明明写的 31 号,为什么生成的对象是 30 号的?因为 new Date 把它解析为 2015-03-31 00:00:00 ,时区为 UTC 。美国东部时区是减 4 小时的,于是就变成了前一天 20:00:00 。

那么 new Date 传入的时间字符串有没有规律可循呢?

混乱的规律

new DateDate.parse 使用的是同样的解析规律,只是一个返回 Date object 另一个返回毫秒数。为了方便查看结果,以下例子只用 new Date 。但请记住它们遵循一样的规律。

new Date 可以传入一个日期字符串来生成对象的,官方规定日期字符串需要符合 RFC2822 或者 ISO8601 的格式。拿上面的日期举个例子,前者可以写成 "Mar 31 2015" 后者可以写成 "2015-03-31" 。

如果日期字符串不符合这两种标准,new Date 对结果概不负责……

不过就算符合标准了,结果还是有点不同的。看几个例子:

new Date("Mar 31 2015")    // Tue Mar 31 2015 00:00:00 GMT-0400 (EDT)
new Date("2015-03-31")     // Mon Mar 30 2015 20:00:00 GMT-0400 (EDT)

RFC2822 的格式如果不带时区,new Date 会当做本地时区处理,而 ISO8601 格式则会当做 UTC 时区处理。

是有点绕人,但只要记住这个规律不就完了吗?骚年你太天真了…… 因为 ES6 草案为了简化这种情况,规定所有不带时区的字符串都默认为本地时区。注意这是草案,所以结果你懂的。

解决方案

一种解决方案是每次格式化日期都严格指定时区,以防止各种幺蛾子情况出现,比如:

new Date("2015-03-31T00:00:00-04:00")    // Tue Mar 31 2015 00:00:00 GMT-0400 (EDT)

不过鉴于人都是懒惰的,这种情况交给工具做更靠谱,比如 moment.js 。

moment("2015-03-31").toDate()

参考链接

Date.parse() - JavaScript | MDN

总结

以上是脚本宝典为你收集整理的

JavaScript Date.parse 的小坑

全部内容,希望文章能够帮你解决

JavaScript Date.parse 的小坑

所遇到的程序开发问题,欢迎加入QQ群277859234一起讨论学习。如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典网站推荐给程序员好友。 本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。

80%的人都看过