什么是 JavaScript 中的有效日期时间字符串? [英] What are valid Date Time Strings in JavaScript?

问题描述

在 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 这样的日期库如何处理日期字符串?

_{如果你没有注意到，我回答了我自己的问题(为什么?).}

解决方案

The Essentials

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

请注意，年份必须至少有四位数字，月/日/小时/分钟/秒必须正好有两位数字，毫秒必须em> 正好是三位数字.例如，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.

重要:根据规范，所有现代和相当古老的浏览器和实现都支持全长日期时间格式.然而，在处理没有时区的日期(时间)字符串方面存在差异(有关详细信息，请参阅下面的缺少时区偏移量").您应该不使用没有时区的日期时间字符串(Status 2018).而是传递 unix 时间戳(以毫秒为单位)或不同部分的单独参数Date 构造函数的日期.

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

如果您遇到 Invalid Date 而不是日期对象，您很可能使用了无效的日期时间字符串.

---

现在有更多细节.

日期时间字符串格式

ECMAScript(JavaScript 语言实现的规范)一直支持 新日期 (规范) 和 Date.parse (规范) 自成立以来.但是，第一个版本实际上并没有指定日期时间格式.这在 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') 将导致 无效日期.

延长年份

ECMAScript 的日期时间格式也指定了 extended years 这是六位数的年份值.此类扩展年份字符串格式的示例类似于 [phone]T08:59:00.992Z，表示公元 287396 年的日期.延长年数可以是正数也可以是负数.

日期 API

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

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

还可以使用以下函数检测日期对象是否有效或无效日期.

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

来源和更多信息可以在检测无效日期" JavaScript 中的日期实例.

示例

有效的日期时间格式

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

20182018-012018-01-012018-01-01T00:002018-01-01T00:00:002018-01-01T00:00:00.0002018-01-01T00:00:00.000Z2018-01-01T00:00:00.000+01:002018-01-01T00:00:00.000-01:00+002018-01-01T00:00:00.000+01:00

无效的日期时间格式

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

2018-1-1//月份和日期必须是两位数2018-01-01T0:0:0.0//时/分/秒必须是两位数，毫秒必须是三位数2018-01-01 00:00//空格必须是T"；反而2018-01-01T00//最短时间部分必须有格式 HH:mm2018-01-01T00:00:00.000+01//时区必须有格式 HH:mm

浏览器支持

今天，每个现代且相当老的浏览器都支持 ES5 引入的日期时间格式2009 年的规范.然而，即使在今天(Status 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.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(中欧标准时间)

请注意，括号内的时区名称是可选的，确切的名称是依赖于实现".

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

星期日，2019 年 2 月 3 日 13:27:49 GMT

注意，与Date.prototype.toUTCString()相比，在工作日和日月反转之后有一个逗号,.

由于这些格式仅在 2018 年才被指定，因此您不应依赖它们在不同的实现(尤其是旧浏览器)中同样有效.

Node.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() 的返回值都被指定为依赖于实现".>

When using new Date or Date.parse in JavaScript, I cannot just pass arbitrary date formats. Depending on the format, I get a different date than I wanted to or even Invalid Date instead of a date object. Some date formats work in one browser but not in others. So which date time formats should I use?

Additional questions:

• Do all browsers support the same formats? How do Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, Microsoft Edge, and Apple Safari handle date time strings? What about Node.js?

• Does it take the local date format into consideration? E.g. if I live in Switzerland and the date format is 30.07.2018, can I use new Date('30.07.2018')?

• Does it take the local time zone into consideration?

• How can I get a date time string from a date object?

• How can I detect invalid date time strings?

• How do date libraries like Moment.js handle date strings?

_{In case you did not notice, I answered my own question (why?).}

解决方案

The Essentials

JavaScript officially supports a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ. The letter T is the date/time separator and Z is the time zone offset specified as Z (for UTC) or either + or - followed by a time expression HH:mm. Some parts (e.g. the time) of that format can be omitted.

Note that years must have at least four digits, month/day/hours/minutes/seconds must have exactly two digits, and milliseconds must have exactly three digits. For example, 99-1-1 is not a valid date string.

These are some examples of valid date (time) strings:

• 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

When you omit the time zone offset, date-times are interpreted as user local time. When you omit the time altogether, dates are interpreted as UTC.

Important: All modern and reasonably old browsers and implementations support the full-length date time format according to the specification. However, there are differences in the handling of date (time) strings without a time zone (see "Missing Time Zone Offset" below for details). You should not use date time strings without a time zone (Status 2018). Instead pass a unix timestamp in milliseconds or separate arguments for different parts of the date to the Date constructor.

Most browser also support some other formats but they are not specified and thus don't work in all browsers the same way. If at all, you should only use the date time string formats explained above. Every other format might break in other browsers or even in other versions of the same browser.

If you run into Invalid Date instead of a date object, you most probably are using an invalid date time string.

---

And now with a little more detail.

Date Time String Format

ECMAScript (the specification that the JavaScript language implements) has been supporting date strings in new Date (specification) and Date.parse (specification) since its inception. However, the first versions did not actually specify a date time format. This changed in 2009 when ES5 was introduced with a specification of a date time format.

The Basics

ECMAScript specifies the Date Time String Format as a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ.

• YYYY is the decimal digits of the year 0000 to 9999 in the proleptic Gregorian calendar.
• - (hyphen) appears literally twice in the string.
• MM is the month of the year from 01 (January) to 12 (December).
• DD is the day of the month from 01 to 31.
• T appears literally in the string, to indicate the beginning of the time element.
• HH is the number of complete hours that have passed since midnight as two decimal digits from 00 to 24.
• : (colon) appears literally twice in the string.
• mm is the number of complete minutes since the start of the hour as two decimal digits from 00 to 59.
• ss is the number of complete seconds since the start of the minute as two decimal digits from 00 to 59.
• . (dot) appears literally in the string.
• sss is the number of complete milliseconds since the start of the second as three decimal digits.
• Z is the time zone offset specified as "Z" (for UTC) or either "+" or "-" followed by a time expression HH:mm

The specification also mentions that if "the String does not conform to [the specified] format the function may fall back to any implementation-specific heuristics or implementation-specific date formats" which might result in different dates in different browsers.

ECMAScript does not take any user local date time formats into account which means that you can not use country or region-specific date time formats.

Short Date (and Time) Forms

The specification also includes shorter formats as follows.

This format includes date-only forms:

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

It also includes "date-time" forms that consist of one of the above date-only forms immediately followed by one of the following time forms with an optional time zone offset appended:

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

Fallback Values

[...] If the MM or DD fields are absent "01" is used as the value. If the HH, mm, or ss fields are absent "00" is used as the value and the value of an absent sss field is "000". When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

See "Missing Time Zone Offset" below for more information on the lacking browser support.

Out of Bound Values

Illegal values (out-of-bounds as well as syntax errors) in a format string means that the format string is not a valid instance of this format.

For example, new Date('2018-01-32') and new Date('2018-02-29') will result in a Invalid Date.

Extended Years

The date time format of ECMAScript also specifies extended years which are six digit year values. An example of such an extended year string format looks like [phone]T08:59:00.992Z which denotes a date in the year 287396 A.D. Extended years can either be positive or negative.

Date API

ECMAScript specifies a wide range of date object properties. Given a valid date object, you can use Date.prototype.toISOString() to get a valid date time string. Note that the time zone is always UTC.

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

It is also possible to detect whether a date object valid or an Invalid Date using the following function.

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

Source and more information can be found in Detecting an "invalid date" Date instance in JavaScript.

Examples

Valid Date Time Formats

The following date time formats are all valid according to the specification and should work in every browser, Node.js or other implementation that supports ES2016 or higher.

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

Invalid Date Time Formats

Note that the following examples are invalid as per the specification. However, that does not mean that no browser or other implementation interprets them to a date. Please do not use any of the date time formats below as they are non-standard and might fail in some browsers or browser versions.

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

Browser Support

Today, every modern and reasonably old browser supports the date time format that was introduced with the ES5 specification in 2009. However, even today (Status 2018) there are different implementations for date time strings without a time zone (see "Missing Time Zone Offset" below). If you need to support older browsers or use strings without a time zone, you should not use date time strings. Instead, pass a number of milliseconds since January 1, 1970, 00:00:00 UTC or two or more arguments representing the different date parts to the Date constructor.

Missing Time Zone Offset

ES5.1 incorrectly states that the value of an absent time zone offset is "Z" which contradicts with ISO 8601. This mistake was fixed in ES6 (ES2015) and extended on in ES2016 (see "Changes to the ECMAScript Specifications" below). As of ES2016, date time strings without a time zone are parsed as local time while date only strings are parsed as UTC.

According to this answer, some implementations never implemented the behaviour specified in ES5.1. One of them seems to be Mozilla Firefox. Other browsers that seem to be compliant with the specification of ES2016 (and higher) are Google Chrome 65+, Microsoft Internet Explorer 11, and Microsoft Edge. The current version of Apple Safari (11.1.2) is not compliant as it erroneously parses date time strings without a time zone (e.g. 2018-01-01T00:00) as UTC instead of local time.

Legacy Date Time Formats

ES5 introduced a specification for date time strings in 2009. Before that, there were no specified formats that were supported by all browsers. As a result, each browser vendor added support for different formats which often did not work accross different browsers (and versions). For a small example of ancient history, see date-formats.

Most browsers still support those legacy formats in order to not break the backward compatibility of older websites. But it is not safe to rely on those non-standard formats as they might be inconsistent or get removed at any time.

Date.prototype.toString() and Date.prototype.toUTCString()

ES2018 for the first time specified the date format that is returned by Date.prototype.toString() and Date.prototype.toUTCString(). Already before that, the ECMA Specification required the Date constructor and Date.parse to correctly parse the formats returned by those methods (even though it did not specify a format before 2018).

An example return value of Date.prototype.toString() may look like this:

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

Note that the timezone name within brackets is optional and the exact name is "implementation-dependent".

Date.prototype.toUTCString() returns a date in a similar format as Date.prototype.toString() but with a zero timezone offset. An example format may look like this:

Sun, 03 Feb 2019 13:27:49 GMT

Note that there is a comma , after the weekday and day month are reversed compared to Date.prototype.toUTCString().

As those formats have only been specified in 2018, you should not rely on them working equally in different implementations (especially older browsers).

Node.js

Node.js is running on the V8 JavaScript engine which is also used in Google Chrome. So the same specification regarding the date time string format applies. As the code runs in the backend though, the user local time does not influence the time zones but only the settings on the server do. Most platform as a service (PaaS) provider that host Node.js applications use UTC as their default time zone.

Date Time Libraries

Moment.js

Moment.js is a very popular library to help with the handling of dates in JavaScript and it also supports more formats than ECMAScript specifies. In addition, Moment.js also supports creating date objects based on a string and a arbitrary format.

Luxon

Luxon supports parsing of ISO 8601, HTTP, RFC2822, SQL, and arbitrary formats. But only using different functions for different date time formats.

Changes to the ECMAScript Specifications

A list of notable changes in the ECMAScript specifications regarding date time string formats.

Changes in ES2018

Introduces a specification for the date formats returned by Date.prototype.toString() and Date.prototype.toUTCString().

Changes in ES2017

No notable changes.

Changes in ES2016

If the time zone offset is absent, the date-time is interpreted as a local time.

When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

Changes in ES6 (ES2015)

The value of an absent time zone offset is "Z".

If the time zone offset is absent, the date-time is interpreted as a local time.

_{From Corrections and Clarifications in ECMAScript 2015 with Possible Compatibility Impact:}

If a time zone offset is not present, the local time zone is used. Edition 5.1 incorrectly stated that a missing time zone should be interpreted as "z".

_{See Date Time String Format: default time zone difference from ES5 not web-compatible for more details on that change.}

Changes in ES5.1

If the MM or DD fields are absent "01" is used as the value. If the HH, mm, or ss fields are absent "00" is used as the value and the value of an absent sss field is "000". The value of an absent time zone offset is "Z".

Changes in ES5

First introduction of a date time string format to the ECMAScript specification.

ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ

Also introduces Date.prototype.toISOString() which returns a date time string in that specified format.

Changes in ES3

Deprecates Date.prototype.toGMTString() and replaces it with Date.parse(x.toUTCString()) in the section mentioning that the format returned by these methods must be correctly parseable by implmentations of Date.parse. Note that the format returned by Date.parse(x.toUTCString()) is "implementation-dependent".

Changes in ES2

No notable changes.

Initial Specification: ES1

ES1 introduced date time strings to be used in new Date(value) and Date.parse(value). However, it did not specify an actual date (time) format, it even states that

[...] the value produced by Date.parse is implementation dependent [...]

The specification also mentions that

If x is any Date object [...], then all of the following expressions should produce the same numeric value in that implementation [...]:

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

However, the returned value of both Date.prototype.toString() and Date.prototype.toGMTString() were specified as "implementation dependent".

这篇关于什么是 JavaScript 中的有效日期时间字符串?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！