什么是 JavaScript 中的有效日期时间字符串？

Question

在 JavaScript 中使用new Date或Date.parse时，我不能只传递任意日期格式。 根据格式，我得到的日期与我想要的不同，甚至是Invalid Date ，而不是日期对象。 某些日期格式适用于一种浏览器，但不适用于其他浏览器。 那么我应该使用哪些日期时间格式？

附加问题：

• 所有浏览器都支持相同的格式吗？ Mozilla Firefox、Google Chrome、Microsoft Internet Explorer、Microsoft Edge 和 Apple Safari 如何处理日期时间字符串？ Node.js 呢？

• 是否考虑本地日期格式？ 例如，如果我住在瑞士并且日期格式是 30.07.2018，我可以使用new Date('30.07.2018')吗？

• 是否考虑当地时区？

• 如何从日期对象中获取日期时间字符串？

• 如何检测无效的日期时间字符串？

• Moment.js 之类的日期库如何处理日期字符串？

_{如果您没有注意到，我回答了我自己的问题（为什么？ ）。}

Answer 1

要点

JavaScript 正式支持 ISO 8601 扩展格式的简化。 格式如下： YYYY-MM-DDTHH:mm:ss.sssZ 。 字母T是日期/时间分隔符， Z是指定为Z （对于 UTC）或+或-后跟时间表达式HH:mm的时区偏移量。 该格式的某些部分（例如时间）可以省略。

请注意，年必须至少有四位数字，月/日/小时/分钟/秒必须恰好有两位数字，毫秒必须恰好有三位数字。 例如， 99-1-1不是有效的日期字符串。

以下是一些有效日期（时间）字符串的示例：

• 2018-12-30
• 2018-12-30T20:59
• 2018-12-30T20:59:00
• 2018-12-30T20:59:00.000Z
• 2018-12-30T20:59:00.000+01:00
• 2018-12-30T20:59:00.000-01:00

当您省略时区偏移时，日期时间将被解释为用户本地时间。 当您完全省略时间时，日期将被解释为 UTC。

重要提示：所有现代和相当旧的浏览器和实现都支持根据规范的全长日期时间格式。 但是，没有时区的日期（时间）字符串的处理存在差异（有关详细信息，请参阅下面的“缺少时区偏移”）。 您不应使用没有时区的日期时间字符串（状态 2018）。 而是将unix 时间戳（以毫秒为单位）或日期不同部分的单独参数传递给Date构造函数。

大多数浏览器也支持一些其他格式，但它们没有被指定，因此不能在所有浏览器中以相同的方式工作。 如果有的话，您应该只使用上面解释的日期时间字符串格式。 其他所有格式都可能在其他浏览器甚至同一浏览器的其他版本中中断。

如果您遇到Invalid Date而不是 date 对象，则很可能是在使用无效的 date time 字符串。

---

现在有更多细节。

日期时间字符串格式

ECMAScript（JavaScript 语言实现的规范）从一开始就支持new Date (specification ) 和Date.parse (specification ) 中的日期字符串。 但是，第一个版本实际上并没有指定日期时间格式。 这在 2009 年发生了变化，当时 ES5 引入了日期时间格式的规范。

基础知识

ECMAScript 将日期时间字符串格式指定为ISO 8601 扩展格式的简化。 格式如下： YYYY-MM-DDTHH:mm:ss.sssZ 。

• YYYY是公历中 0000 到 9999 年的十进制数字。
• - （连字符）在字符串中按字面意思出现两次。
• MM是一年中的月份，从 01（一月）到 12（十二月）。
• DD是一个月中的一天，从 01 到 31。
• T按字面意思出现在字符串中，表示时间元素的开始。
• HH是自午夜以来经过的完整小时数，以 00 到 24 之间的两位小数表示。
• :冒号）在字符串中出现两次。
• mm是自一小时开始以来的完整分钟数，为从 00 到 59 的两位十进制数字。
• ss是自分钟开始以来的完整秒数，为从 00 到 59 的两位十进制数字。
• . （点）字面上出现在字符串中。
• sss是自秒开始以来的完整毫秒数，以十进制三位数字表示。
• Z是指定为“Z”（对于 UTC）或“+”或“-”后跟时间表达式HH:mm的时区偏移量

该规范还提到，如果“字符串不符合 [指定] 格式，则函数可能会退回到任何特定于实现的启发式或特定于实现的日期格式”，这可能会导致不同浏览器中的日期不同。

ECMAScript 不考虑任何用户本地日期时间格式，这意味着您不能使用特定于国家或地区的日期时间格式。

短日期（和时间）表格

该规范还包括如下较短的格式。

此格式包括仅日期形式：

• YYYY
• YYYY-MM
• YYYY-MM-DD

它还包括“日期-时间”形式，其中包括上述仅日期形式之一，紧随其后的是以下时间形式之一，并附加了可选的时区偏移量：

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

后备值

[...] 如果MM或DD字段不存在，则使用"01"作为值。 如果HH 、 mm或ss字段不存在，则使用"00"作为值，并且不存在的sss字段的值为"000" 。 当时区偏移不存在时，仅日期形式被解释为 UTC 时间，而日期时间形式被解释为本地时间。

有关缺少浏览器支持的更多信息，请参阅下面的“缺少时区偏移”。

超出范围的值

格式字符串中的非法值（越界以及语法错误）意味着该格式字符串不是该格式的有效实例。

例如， new Date('2018-01-32')和new Date('2018-02-29')将导致Invalid Date 。

延长年限

ECMAScript 的日期时间格式还指定了扩展年份，即六位数年份值。 这种扩展年份字符串格式的示例类似于+287396-10-12T08:59:00.992Z ，它表示公元 287396 年中的日期扩展年份可以是正数或负数。

日期 API

ECMAScript 指定了范围广泛的日期对象属性。 给定一个有效的日期对象，您可以使用Date.prototype.toISOString()来获取一个有效的日期时间字符串。 请注意，时区始终为 UTC。

new Date().toISOString() // "2018-08-05T20:19:50.905Z"

还可以使用以下函数检测日期对象是有效还是Invalid Date 。

function isValidDate(d) {
  return d instanceof Date && !isNaN(d);
}

来源和更多信息可以在Detecting an “invalid date” Date instance in JavaScript 中找到。

例子

有效的日期时间格式

以下日期时间格式根据规范都是有效的，并且应该适用于所有支持 ES2016 或更高版本的浏览器、Node.js 或其他实现。

2018
2018-01
2018-01-01
2018-01-01T00:00
2018-01-01T00:00:00
2018-01-01T00:00:00.000
2018-01-01T00:00:00.000Z
2018-01-01T00:00:00.000+01:00
2018-01-01T00:00:00.000-01:00
+002018-01-01T00:00:00.000+01:00

无效的日期时间格式

请注意，根据规范，以下示例无效。 但是，这并不意味着没有浏览器或其他实现将它们解释为日期。 请不要使用以下任何日期时间格式，因为它们是非标准的，并且可能在某些浏览器或浏览器版本中失败。

2018-1-1 // month and date must be two digits
2018-01-01T0:0:0.0 // hour/minute/second must be two digits, millisecond must be three digits
2018-01-01 00:00 // whitespace must be "T" instead
2018-01-01T00 // shortest time part must have format HH:mm
2018-01-01T00:00:00.000+01 // time zone must have format HH:mm

浏览器支持

今天，每个现代和相当旧的浏览器都支持 2009 年随 ES5 规范引入的日期时间格式。然而，即使在今天（2018 年状态），没有时区的日期时间字符串也有不同的实现（参见“缺少时区偏移” “ 以下）。 如果您需要支持较旧的浏览器或使用没有时区的字符串，则不应使用日期时间字符串。 相反，将自 1970 年 1 月 1 日 00:00:00 UTC 起的毫秒数或表示不同日期部分的两个或多个参数传递给Date构造函数。

缺少时区偏移

ES5.1 错误地指出不存在时区偏移的值是“Z” ，这与 ISO 8601 相矛盾。这个错误在ES6（ES2015）中得到了修复，并在ES2016中得到了扩展（参见下面的“对 ECMAScript 规范的更改”）。 从 ES2016 开始，没有时区的日期时间字符串被解析为本地时间，而只有日期的字符串被解析为 UTC。

根据这个答案，一些实现从未实现 ES5.1 中指定的行为。 其中之一似乎是 Mozilla Firefox。 其他似乎符合 ES2016（及更高版本）规范的浏览器是 Google Chrome 65+、Microsoft Internet Explorer 11 和 Microsoft Edge。 当前版本的 Apple Safari (11.1.2)不兼容，因为它错误地将没有时区的日期时间字符串（例如2018-01-01T00:00 ）解析为 UTC 而不是本地时间。

旧版日期时间格式

ES5 在 2009 年引入了日期时间字符串的规范。在此之前，没有指定的格式被所有浏览器支持。 结果，每个浏览器供应商都添加了对不同格式的支持，这些格式通常在不同的浏览器（和版本）上不起作用。 有关古代历史的一个小例子，请参阅date-formats 。

大多数浏览器仍然支持这些旧格式，以免破坏旧网站的向后兼容性。 但是依赖这些非标准格式是不安全的，因为它们可能会不一致或随时被删除。

Date.prototype.toString()和Date.prototype.toUTCString()

ES2018 首次指定了Date.prototype.toString()和Date.prototype.toUTCString()返回的日期格式。 在此之前，ECMA 规范要求Date构造函数和Date.parse正确解析这些方法返回的格式（即使它在 2018 年之前没有指定格式）。

Date.prototype.toString()的示例返回值可能如下所示：

Sun Feb 03 2019 14:27:49 GMT+0100 (Central European Standard Time)

请注意，括号中的时区名称是可选的，确切的名称是“依赖于实现的”。

Date.prototype.toUTCString()以与Date.prototype.toString()类似的格式返回日期，但时区偏移量为零。 示例格式可能如下所示：

Sun, 03 Feb 2019 13:27:49 GMT

请注意，与Date.prototype.toString()相比,在 weekday 和 day 月份反转之后有一个逗号。

由于这些格式仅在 2018 年指定，因此您不应依赖它们在不同的实现（尤其是旧浏览器）中同样工作。

节点.js

Node.js 在 V8 JavaScript 引擎上运行，该引擎也用于 Google Chrome。 因此，有关日期时间字符串格式的相同规范也适用。 由于代码在后端运行，因此用户本地时间不会影响时区，而只会影响服务器上的设置。 大多数托管 Node.js 应用程序的平台即服务 (PaaS) 提供商使用 UTC 作为其默认时区。

日期时间库

Moment.js

Moment.js是一个非常流行的库，可以帮助处理 JavaScript 中的日期，它还支持比 ECMAScript 指定的格式更多的格式。 此外，Moment.js 还支持基于字符串和任意格式创建日期对象。

卢克森

Luxon支持解析ISO 8601、HTTP、RFC2822、SQL 和任意格式。 但仅对不同的日期时间格式使用不同的函数。

ECMAScript 规范的更改

ECMAScript 规范中有关日期时间字符串格式的显着变化列表。

ES2018的变化

介绍Date.prototype.toString()和Date.prototype.toUTCString()返回的日期格式规范。

ES2017的变化

没有显着变化。

ES2016的变化

如果不存在时区偏移量，则日期时间将被解释为本地时间。

当时区偏移不存在时，仅日期形式被解释为 UTC 时间，而日期时间形式被解释为本地时间。

ES6 (ES2015)的变化

缺席时区偏移的值为 “Z” 。

如果不存在时区偏移量，则日期时间将被解释为本地时间。

_{来自ECMAScript 2015 中的更正和澄清可能会影响兼容性：}

如果不存在时区偏移量，则使用本地时区。 5.1 版错误地指出缺少的时区应解释为"z" 。

_{有关该更改的更多详细信息，请参阅日期时间字符串格式：与 ES5 不兼容网络的默认时区差异。}

ES5.1的变化

如果MM或DD字段不存在，则使用“01”作为值。 如果HH 、 mm或ss字段不存在，则使用“00”作为值，并且不存在的sss字段的值为“000” 。 缺席时区偏移的值为“Z” 。

ES5的变化

首次将日期时间字符串格式引入 ECMAScript 规范。

ECMAScript 基于 ISO 8601 扩展格式的简化定义了日期时间的字符串交换格式。 格式如下： YYYY-MM-DDTHH:mm:ss.sssZ

还引入了Date.prototype.toISOString() ，它返回指定格式的日期时间字符串。

ES3的变化

弃用Date.prototype.toGMTString()并将其替换为Date.parse(x.toUTCString())一节中提到这些方法返回的格式必须可以通过Date.parse的实现正确解析。 请注意， Date.parse(x.toUTCString())返回的格式是“依赖于实现的”。

ES2的变化

没有显着变化。

初始规格： ES1

ES1 引入了用于new Date(value)和Date.parse(value)的日期时间字符串。 但是，它没有指定实际的日期（时间）格式，它甚至指出

[...] Date.parse产生的值取决于实现 [...]

该规范还提到

如果x是任何 Date 对象 [...]，则以下所有表达式都应在该实现中产生相同的数值 [...]：

• [...]
• Date.parse(x.toString())
• Date.parse(x.toGMTString())

但是， Date.prototype.toString()和Date.prototype.toGMTString()的返回值都被指定为“依赖于实现”。

Answer 2

那么我应该使用哪些日期时间格式？

一般建议是根本不使用内置解析器，因为它不可靠，因此“应该”的答案是“无”。 请参阅为什么 Date.parse 给出不正确的结果？

但是，正如 str 所说，您可能会使用 ECMA-262 中指定的格式和时区： YYYY-MM-DDTHH:mm:ss.sssZ或YYYY-MM-DDTHH:mm:ss.sss±HH:mm ，不要'不信任任何其他格式。

所有浏览器都支持相同的格式吗？

不。

Mozilla Firefox、Google Chrome、Microsoft Internet Explorer、Microsoft Edge 和 Apple Safari 如何处理日期时间字符串？

不同。 除 ECMA-262 格式之外的任何内容都取决于实现，并且在解析 ECMA-262 格式时存在错误。

Node.js 呢？

可能再次不同，见上文。

是否考虑本地日期格式？ 例如，如果我住在瑞士并且日期格式是 30.07.2018，我可以使用 new Date('30.07.2018') 吗？

也许。 由于它不是标准格式，解析依赖于实现，所以也许，也许不是。

是否考虑当地时区？

它使用将字符串解析为本地的主机时区偏移量，并生成使用本地时间显示的字符串。 否则它使用 UTC（并且内部时间值是 UTC）。

如何从日期对象中获取日期时间字符串？

Date.parse.toString ，或查看在哪里可以找到有关在 JavaScript 中格式化日期的文档？

如何检测无效的日期时间字符串？

这里的前 3 个答案之一应该回答这个问题。

Moment.js 之类的日期库如何处理日期字符串？

他们根据默认或提供的格式解析它们。 阅读源代码（例如，fecha.js是一个简单的解析器和格式化程序，代码编写良好，易于遵循）。

解析器并不难编写，但尝试猜测输入格式（就像内置解析器倾向于做的那样）在不同的实现中是令人担忧的、不可靠的和不一致的。 所以解析器应该要求提供格式，除非输入字符串是解析器的默认格式。

附言

在 ECMAScript 2019（目前处于草案中）中，实现必须支持解析和格式化的字符串格式发生了变化，但我认为避免内置解析器的一般建议将持续一段时间。