在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）如何处理日期字符串？
如果你没有注意到，我自己回答了这个问题（为什么？）。
JavaScript 官方支持 ISO 8601 扩展格式的简化版。格式如下：YYYY-MM-DDTHH:mm:ss.sssZ。字母 T 是日期时间分隔符，Z 是时区偏移量，指定为 Z（表示 UTC）或者是 + 或 - 后跟一个时间表达式 HH:mm。
该格式的某些部分（例如时间）可以省略。
请注意，年份必须至少有四位数字，月/日/小时/分钟/秒钟必须恰好有两位数字，毫秒必须恰好有三位数字。例如，99-1-1 不是有效的日期字符串。
以下是一些有效的日期（时间）字符串示例：
2018-12-302018-12-30T20:592018-12-30T20:59:002018-12-30T20:59:00.000Z2018-12-30T20:59:00.000+01:002018-12-30T20:59:00.000-01:00Date构造函数中。Invalid Date而不是日期对象，则很可能使用了无效的日期时间字符串。
现在稍微详细说明一下。
ECMAScript（JavaScript语言实现的规范）从一开始就支持new Date（规范）和Date.parse（规范）中的日期字符串。
然而，最初的版本并没有指定日期时间格式。
这在2009年ES5被引入并规范了一个日期时间格式时发生了改变。
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 不考虑任何用户本地日期时间格式，这意味着您不能使用特定于国家或地区的日期时间格式。
该规范还包括以下简短格式。
此格式包括仅日期表单：
YYYYYYYY-MMYYYY-MM-DD它还包括“日期时间”形式，由上述仅日期形式之一紧接着下列时间形式之一组成，并附加一个可选的时区偏移量：
THH:mmTHH:mm:ssTHH: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 年的一个日期。
扩展年份可以是正数也可以是负数。
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);
}
源代码和更多信息可以在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
如今，每个现代化和相当旧的浏览器都支持ES5规范在2009年引入的日期时间格式。
然而，即使在今天（状态为2018），没有时区的日期时间字符串有不同的实现（请参见下面的“缺少时区偏移量”）。
如果您需要支持旧版浏览器或使用没有时区的字符串，则不应使用日期时间字符串。
相反，传递自1970年1月1日00:00:00 UTC以来的毫秒数或表示不同日期部分的两个或更多参数到Date构造函数中。
ES5.1 错误地 声明缺失时区偏移量的值为 “Z”，这与 ISO 8601 相矛盾。
该错误已在 ES6（ES2015） 中得到修正，并在 ES2016 中得到扩展（请参见下文中的“ECMAScript 规范的更改”）。
从 ES2016 开始，没有时区的日期时间字符串将被解析为本地时间，而仅有日期的字符串将被解析为 UTC。
2018-01-01T00:00）解析为 UTC 而不是本地时间。
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()相比是颠倒的。Moment.js是一个非常流行的JavaScript日期处理库，它支持比ECMAScript规定更多的格式。此外，Moment.js还支持基于字符串和任意格式创建日期对象。
Luxon支持ISO 8601、HTTP、RFC2822、SQL和任意格式的解析。但是需要使用不同的函数来处理不同的日期时间格式。
关于日期时间字符串格式方面，以下是ECMAScript规范的一些重要更改。
ES2018中的更改
介绍了由Date.prototype.toString()和Date.prototype.toUTCString()返回的日期格式规范。
ES2017中的更改
没有显着的更改。
ES2016中的更改
如果时区偏移量不存在，则将日期时间解释为本地时间。当时区偏移量不存在时，只有日期的形式被解释为UTC时间，日期时间的形式被解释为本地时间。
ES6 (ES2015)的变化
缺失时区偏移量的值为"Z"。如果缺少时间偏移量，则将日期时间解释为本地时间。
来自ECMAScript 2015中的更正和澄清，可能会影响兼容性:
如果不存在时间偏移量，则使用本地时区。第5.1版错误地说明缺少时间区域应该被解释为
"z"。
有关此更改的更多详细信息，请参见日期时间字符串格式：默认时区差异从ES5到Web不兼容。
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.parse(x.toString())Date.parse(x.toGMTString())
然而，Date.prototype.toString()和Date.prototype.toGMTString()的返回值被指定为“依赖于实现”。
那么我应该使用哪些日期时间格式？
一般建议不要使用内置的解析器，因为它不可靠，所以回答“应该”是“没有”。请参见为什么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中如何格式化日期的文档？
如何检测无效的日期时间字符串？
这里的前三个答案之一应该可以回答这个问题。
日期库（如Moment.js）如何处理日期字符串？
它们根据默认或提供的格式进行解析。阅读源代码（例如，fecha.js是一个简单的解析器和格式化程序，具有编写良好，易于遵循的代码）。
编写一个解析器并不难，但是尝试猜测输入格式（正如内置解析器所做的那样）往往是困难的，不可靠的，并且在不同的实现中表现不一致。因此，除非输入字符串符合解析器的默认格式，否则解析器应要求提供格式。
在ECMAScript 2019（目前处于草案阶段）中，实现必须支持解析和格式化的字符串格式发生了变化，但我认为避免使用内置解析器的一般建议仍将持续一段时间。
Object.prototype.toString.call(d) == '[object Date]' && !isNaN(d)。好的，它有65个字符，而不是30个，但你只需要写一次。;-) - RobG