假设输入是完整的 ISO 8601 字符串，“new Date(string)”在现代浏览器中是不是可靠？

Posted 2023-03-06

【中文标题】假设输入是完整的 ISO 8601 字符串，“new Date(string)”在现代浏览器中是不是可靠？

【英文标题】：Is `new Date(string)` reliable in modern browsers, assuming the input is a full ISO 8601 string?假设输入是完整的 ISO 8601 字符串，“new Date(string)”在现代浏览器中是否可靠？

【发布时间】：2022-01-04 21:27:11

【问题描述】：

由于浏览器不一致，有很多关于不使用new Date(string)（或javascript中的等效Date.parse(string)）的警告。MDN has this to say：

在 ES5 之前不建议使用 Date.parse，字符串的解析完全依赖于实现。不同主机解析日期字符串的方式仍有很多差异，因此应手动解析日期字符串（如果要适应许多不同的格式，库可以提供帮助）。

但是，当您继续阅读时，大多数关于特定于实现的行为的警告似乎都是针对以下情况的：

旧版浏览器（例如，ES5 之前旧版） 非 ISO 8601 输入（例如 "March 6th 2015"） 不完整的 ISO 8601 输入（例如 "2015-06-03"，没有时间或时区）

我想知道的是，鉴于这两个假设：

现代浏览器（比如说，2020 年以后的任何浏览器） 完整的 ISO 8601 输入（例如 "2021-11-26T23:04:00.778Z"）

我可以可靠地使用new Date(string)吗？

【问题讨论】：

看看优秀的What are valid Date Time Strings in JavaScript?

【参考方案1】：

是的。 JavaScript 中可接受的日期字符串的格式是标准化的：

ECMAScript 基于 ISO 8601 日历日期扩展格式的简化定义了日期时间的字符串交换格式。格式如下：

    YYYY-MM-DDTHH:mm:ss.sssZ

来自ECMAScript current draft 在“日期时间字符串格式”部分标题下。

这是解析规范中提出的日期字符串的唯一标准，因此日期库的目标是在调用new Date 或Date.parse 之前将日期格式化为这种格式。我无法评论 ISO 标准的“简化”是什么，但帖子中询问的格式与 [ECMAScript] 标准的格式相匹配。

请注意，该标准继续适用于仅声明日期的表格

YYYY YYYY-MM YYYY-MM-DD

被接受，并且时间格式（可选地后跟 UTC 偏移量）为

THH:mm THH:mm:ss THH:mm:ss.sss

可以在日期组件之后使用。

【讨论】：

“我无法评论 ISO 标准的“简化”是什么” - 我们收到了 What is simplified in ECMAScript 5 date format compared to ISO 8601 :-)

这不是唯一支持的格式，实现还必须解析由toString 和toUTCString 生成的格式，这些格式也由ECMA-262 标准化。 ;-)

@RobG 在规范的“日期时间字符串格式”部分的最后一段中对toString 和toUTCString 的引用要求实现能够解析自己的日期格式字符串，但是也不是其他实现的那些。 MDN 重复同样的事情。但是，toString 和 toDateString 的标准化使日期时间字符串格式部分本身的准确性受到质疑。也许应该更新:)

【参考方案2】：

是的，使用 ISO 8601 输入到new Date 是可靠的。

正如您引用的文档所指出的，这是用 ES5 标准化的，根据MDN's compatibility table，Internet Exploder 8 (RIP) 是最后一个不支持它的浏览器。

【讨论】：

嗯，只有 ECMA-262 支持的两种特定的 ISO 格式，而不是一般的 ISO 8601 格式。 :-)