javascript - 在 JavaScript 中创建新日期时的奇怪行为

Question

我正在研究 JavaScript 中的 Date 对象，发现了一个非常奇怪的行为。

如果您创建一个包含 1 个参数的新日期并调用 getFullYear 方法，它将返回比您传入的值少 1

new Date("2014").getFullYear()
=> 2013

为了测试一个理论，它会返回“2014-1-1”，并且在前一年的前一个时区，我做了另一个测试。

new Date("2014").getDate()
=> 31

new Date("2014").getMonth()
=> 11

这将支持时区理论，但它仍然无法解释接下来的两个示例。

如果您输入字母数字字符串，您将获得正确的年份。它甚至适用于像这样的乱码

new Date("hsdkjfuweirsdf 2014").getFullYear();
=> 2014

对于第一个示例，我假设函数从 0 开始计数，因此年份会少 1。但是，这并不能解释为什么我的第二个函数返回正确的年份。

编辑:

我在 new Date() 构造函数中发现了另一个奇怪的行为。如果传入多个参数，它也会返回正确的年份

new Date("2014", "9").getFullYear()
=> 2014

以上所有测试均在 Google Chrome 中进行了多次。

Answer 1

在第一种情况下，日期字符串被检测为部分遵循官方 Date Time String Format :

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

并且，至少在 ECMAScript 的第 5 版中，您的浏览器当前遵循的是:

The value of an absent time zone offset is “Z”.

这样，日期字符串就被假定为 UTC/GMT 时间进行解析。

Date.parse("2014") === Date.parse("2014-01-01T00:00:00Z");

然后，与等效的 UTC 方法相比，getFullYear() 提供您本地时区同一“时刻”的年份。

new Date("2014").getFullYear()    // 2013 (or 2014 for users in UTC+N timezones)
new Date("2014").getHours()       // (not 0, unless you live in UTC+0)

new Date("2014").getUTCFullYear() // 2014
new Date("2014").getUTCHours()    // 0

<小时/>

第二个示例在年份之前包含了乱码，因此与上述格式不匹配，甚至部分不匹配。

由于这是规范中正式定义的唯一格式，因此浏览器现在为 on its own to determine if and how it should parse the date string .

If the String does not conform to [the Date Time String Format] the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

并且，它默认选择使用您本地的时区，并在很大程度上忽略乱码。

new Date("hsdkjfuweirsdf 2014").getFullYear() // 2014
new Date("hsdkjfuweirsdf 2014").getHours()    // 0

<小时/>

注意:most recent, 6th edition of ECMAScript更改了缺少时区的日期字符串的假定值:

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