为什么20250528和2025-05-28在JavaScript中是不同的日子？

译者 | 平川

策划 | Tina

在搭建这个网站的过程中，我遇到了以下奇怪的事情：

console. log( newDate( '2025/05/28'). toDateString); // Wed May 28 2025console. log( newDate( '2025-05-28'). toDateString); // Tue May 27 2025// 去掉月份的 0console. log( newDate( '2025-5-28'). toDateString); // Wed May 28 2025

你在你的机器上可能会得到不同的结果。

发生了什么？

在 Java 中，Date代表一个时间点（即自纪元以来的毫秒数）。把完整的日期字符串打印出来就更明显了：

constdate = new Date(' 2025/ 05/ 28'); console.log(date); // Wed May 28202500: 00: 00GMT- 0700(Pacific Daylight Time) console.log(date.toDateString); // Wed May 282025

在这种情况下，传入的日期字符串被解释成我所在时区的一个时间戳。toDateString 的操作也是相对于本地时间，所以我们得到了相同的月份日期。

和'2025-05-28'的区别在于解析行为。这个字符串被解释为 UTC，所以最终得到了不同的时间点：

constdate = new Date(' 2025- 05- 28'); console.log(date); // Tue May 27202517: 00: 00GMT- 0700(Pacific Daylight Time) console.log(date.toDateString); // Tue May 272025

为什么会有这种差异？

浏览器日期解析的冒险

在翻阅 Chrome/Firefox/Safari 的代码和提交历史后，我重建了一个时间线：

• 2009 年，这些浏览器支持解析一系列日期 - 时间格式。当字符串中没有明确指定时区偏移时，它们都会转而使用本地时间，包括像'2025/05/28'这样的日期字符串。

• ES5 在 2009 年年底发布，要求支持一种新的标准化日期 - 时间格式。在很大程度上，这种格式基于 ISO 8601。这种格式被分为仅日期形式（如'2025-05-28'）和日期 - 时间形式（如'2025-05-27T17:00-07:00'），其中末尾的 UTC 是可选的。

• 对于没有偏移的仅日期形式或缺少偏移的日期 - 时间形式，关于时区解释，规范说了什么？只是说“字符串可能被解释为本地时间、UTC 时间或某个其他时区的时间，这取决于字符串的内容。”

• Firefox 是第一个实现这一要求的。他们选择将仅日期形式解释为 UTC，将缺少偏移的日期 - 时间形式解释为本地时间。现在，不仅'2025/05/28'和'2025-05-28'之间存在差异，而且还有令人惊讶的行为，如下所示：

console.log(new Date(' 2025- 05- 28')); // Tue May 27202517: 00: 00GMT- 0700(Pacific Daylight Time) console.log(new Date(' 2025- 05- 28T00: 00')); // Wed May 28202500: 00: 00GMT- 0700(Pacific Daylight Time)

• 接下来是 Chrome，选择对两者都使用本地时间。

• 接下来是 Safari，但它的解析逻辑错误地要求必须提供日期、时间和偏移字段。

• ES5.1 在 2011 年中发布，其中提到，缺少的时区偏移值为 Z。

• Chrome 更新了其实现，对两种情况都使用 UTC。

• Safari 修复了早期的 Bug，对两种情况都使用 UTC。

• 有人提出了规范本身的一个 Bug，ISO 8601 将没有偏移的日期 - 时间表示为本地时间。2015 年，ES6 取代了 ES5.1，并补充道“如果不存在时区偏移，则将日期 - 时间解释为本地时间”。

• Chrome 切换回对两种情况都使用本地时间。

• 有人提出了 Chrome 的一个 Bug，它在解析仅日期形式时破坏了向后兼容性。他们撤销了之前的更改。

• Chrome 提出了规范的一个 问题，经过讨论之后，仅日期形式切换回 UTC，但将缺少偏移的日期 - 时间形式仍为本地（即 Firefox 2009 年的行为）。

• ES7 发布更新后的要求，Chrome 先做了更改，然后是 Safari。

这种行为一直维持到今天，除了像'2025-05-28'这样的有效 ISO 日期字符串之外，Date 构造函数会将接收到的每个可能的字符串都作为本地时间。

有趣的是，从 2009 年发布到 2025 年初，尽管被设计为标准格式，主要浏览器在处理缺少偏移的情况时从未一致过。与此同时，在解析'2025-05-28T00:00'时，Chrome 经历了多次反复（local → UTC → local → UTC → local ）。而这一切只是为了解决 Firefox 2009 年的行为问题，在我看来，它是所有行为中最不直观的。

Java Temporal

Java Temporal 即将面世：这是一组新的日期和时间 API，旨在取代 Date 对象。

整个日期解析问题最初是源于时区歧义，但在很多情况下，我们希望将仅日期字符串视为纯日期。例如，当我说今年的圣诞节是 2025-12-25 时，我指的并不是 2025-12-25T00:00:00.000Z 这个时间。

Date 只能表示后者，而 Temporal 则提供了 纯日期（即不含时区的日期）选项。 '2025-12-25'就是 2025-12-25，完全避免了解析歧义的问题。