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

在日常生活中，“2025/05/28” 和 “2025-05-28” 可能只是两种日期写法的区别——前者看起来更像美式格式，后者则更标准化一些。但在编程世界里，这种写法的不同，可能意味着完全不同的时间点。特别是在 JavaScript 中，这两者居然会被解析成不同的一天！

这种现象最近在 Hacker News 上引发了不少关注，不少开发者都表示曾在这类问题上“踩坑”甚至 debug 到深夜。一位网友就评论说：“我调了半天的日期 bug，最后才发现是字符串写法惹的祸。”还有人惊呼：“我们都以为是用户格式输错，结果是 JavaScript 的锅。”

对此，开发者 Brandon Dong 专门写了一篇《Why are 2025/05/28 and 2025-05-28 different days in JavaScript?》文章深入分析了背后的原因，不仅揭示了 Date 构造函数令人费解的行为，还带你回顾了一段浏览器与 ECMAScript 标准之间十多年来“反复横跳”的历史。接下来就让我们一起看看，JavaScript 为什么会把明明写着“2025 年 5 月 28 日”的两个字符串，解析成两个不一样的时间点。

原文链接：https://brandondong.github.io/blog/javascript_dates/

作者 | Brandon Dong

翻译 | 苏宓

出品 | CSDN（ID：CSDNnews）

在搭建个人网站的过程中，我遇到了一个奇怪的现象：

console.log(new Date('2025/05/28').toDateString()); // Wed May 28 2025
console.log(new Date('2025-05-28').toDateString()); // Tue May 27 2025
// Bonus: (omit leading 0)
console.log(new Date('2025-5-28').toDateString()); // Wed May 28 2025

你在自己电脑上运行时可能会得到不同的结果！

发生了什么？

在 JavaScript 中，一个 Date 对象始终表示一个时间点（即自 Unix 纪元以来的毫秒数）。这一点在输出完整时间字符串时更为明显：

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

在这种情况下，传入的日期字符串被解释为本地时区的时间戳。toDateString() 也相对于本地时间操作，因此我们得到了相同的日期。

而'2025-05-28' 的不同之处在于解析行为；该字符串被解释为 UTC 时间，因此最终处于不同的时间点：

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

为什么会有这种差异？

浏览器日期解析的奇妙旅程

在查阅了 Chrome/Firefox/Safari 的代码和提交历史后，我梳理出了一个时间线：

• 2009 年：各大浏览器支持解析各种日期时间格式。当字符串中没有明确指定时区时，它们默认按本地时间解析，包括像 '2025/05/28' 这样的日期格式。

• 同年晚些时候：即将发布的 ES5 标准提出了一种基于 ISO 8601 的新日期格式标准，包含一种纯日期形式：'2025-05-28'，还有另一种日期+时间形式：'2025-05-27T17:00-07:00'（其中时区偏移可以省略）

  那么对于没有偏移信息的纯日期形式或省略偏移的日期时间形式，规范是怎么说的呢？答案是：字符串的时间可以被解释为本地时间、UTC 时间或其他时区时间，取决于字符串的内容。

• Firefox 是第一个实现这一要求的浏览器。他们选择将仅日期形式解释为 UTC 时间，将缺少偏移量的日期时间形式解释为本地时间。这不仅导致 '2025/05/28' 和 '2025-05-28' 之间存在差异，还出现了令人惊讶的行为，例如：

console.log(new Date('2025-05-28')); // Tue May 27 2025 17:00:00 GMT-0700
console.log(new Date('2025-05-28T00:00')); // Wed May 28 2025 00:00:00 GMT-0700

• 接下来是 Chrome，它选择对这两种情况都使用本地时间。

• 然后是 Safari，但其解析逻辑有 bug：要求必须提供日期、时间和偏移字段。

• 2011 年年中发布的 ES5.1 进一步补充：如果缺少时区偏移，默认用 Z（即 UTC）。

• Chrome 更新了其实现，对两种情况都按 UTC 时间解析。

• Safari 修复 bug，也改为使用 UTC 时间。

• 随后有人指出这种规范本身存在一个 bug：指出 ISO 8601 实际上规定“无偏移的日期时间”应被解释为本地时间。2015 年，ES6 将之前的说法替换为：如果省略时区偏移，日期时间应被解释为本地时间。

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

• 之后又有人抱怨 Chrome 在解析纯日期格式时破坏了兼容性，Chrome 又改回 UTC。

• Chrome 进一步向规范提交问题。经过讨论后，达成折中方案。

• 纯日期形式→ UTC（Firefox 风格）

• 缺偏移的日期时间形式→ 本地时间
  

• ES7正式采用上述行为。Chrome 率先实现，随后 Safari 也跟进。

到今天为止，这个规则仍在沿用：只要传入的是合法的 ISO 日期字符串（如 '2025-05-28'），构造函数就会默认使用 UTC，否则一律用本地时间。

这种行为一直保持到今天，其中 Date 构造函数接受的每个可能的字符串都回退到本地时间，除了像 '2025-05-28' 这样的有效 ISO 日期字符串。

看这个时间线，有趣的是，尽管它被设计为标准化格式，但从 2009 年发布到 2020 年初，主要浏览器在缺少偏移量的情况下从未有过一致的行为。同时，Chrome 在解析 '2025-05-28T00:00' 时搞笑地从本地→UTC→本地→UTC→本地来回切换。而这一切只是为了最终采用 Firefox 2009 年的行为，在我看来，这是所有行为中最不直观的。

那Temporal 呢？

对于不知道的人来说，JavaScript Temporal 即将到来：这是一组新的日期和时间 API，旨在取代 Date 对象。

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

虽然 Date 只能表示后者，但 Temporal 提供了纯日期（即没有时区的日期）的选项。'2025-12-25' 就只是 '2025-12-25'，完全避开了解析歧义的问题。

但是，如果确实想将仅日期的字符串解析为一个时间点呢？当字符串本身缺少时区时，Temporal 会选择哪个时区？

答案是：根本不会让你这么干。

Temporal 在这方面是严格错误（hard error）：必须明确提供时区偏移或时区标识符，否则它就直接抛错，根本不给你机会“犯老毛病”。

2025 全球产品经理大会

2025 年 8 月 15–16 日

北京·威斯汀酒店

2025 全球产品经理大会将汇聚互联网大厂、AI 创业公司、ToB/ToC 实战一线的产品人，围绕产品设计、用户体验、增长运营、智能落地等核心议题，展开 12 大专题分享，洞察趋势、拆解路径、对话未来。