在日常生活中，“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/
在搭建个人网站的过程中，我遇到了一个奇怪的现象：
console.log(new Date('2025/05/28').toDateString()); // Wed May 28 2025console.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-0700console.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 大专题分享，洞察趋势、拆解路径、对话未来。