自Chrome 144起，Temporal API正式引入，为 web 开发带来了一套现代化的日期和时间 API，这也是 Chrome 集成这一长期推进的 TC39 提案的首个稳定版本。Chrome 发布博客重点介绍了这一更新，并将 Temporal 定位为 JavaScript 长期饱受批评的 Date 对象的现代替代方案。
Temporal 以全局命名空间Temporal的形式对外暴露，旨在解决 Date 对象诸多已知的问题，例如，解析规则不清晰、时区处理繁琐、日期算术运算可变等。它为不同的使用场景设计了专门的类型，并且所有运算均返回新值而非修改原有的对象。MDN 将其描述为Date对象的完整替代方案，内置支持时区与日历系统、墙上时间（wall clock）转换、算术运算及格式化功能。
该 API 最具实际价值的特性之一就是，开发者可以仅表示“日期”，而不会意外引入时区和具体时间的信息。例如：
const start = Temporal.PlainDate.from('2026-02-13');const end = start.add({ days: 7 });
当需要关注时区时，该 API 会强制开发者进行显式声明。以前，在将Date格式化为字符串后，开发人员都会担心这个过程中出现隐式转换，现在，ZonedDateTime类型会将时区信息直接嵌入值中：
const now = Temporal.Now.zonedDateTimeISO('Europe/London');const later = now.add({ hours: 2 });
社区对此的讨论混合了欣喜和落地适配的焦虑。 在Reddit上的热门讨论中，开发者们对无需依赖第三方库来处理基础日期逻辑表示欢迎。有评论指出，这一 API 来得太迟了，并细数了Date对象的诸多不足之处，“连日期这种基础功能都要引入第三方库，这一直以来都很让人头疼”。
尽管 Chrome 已正式支持，但 Temporal 的实际落地可能仍会延迟，原因在于并不是所有浏览器都支持该功能，且框架/类库的适配也需要时间，Reddit 上的评论说：
我很好奇各个类库和框架会花费多长时间来适配这个 API，尤其是那些重度依赖调度或数据分析的应用。
近期 Medium 上的一篇文章进一步指出，即便 Chrome 已集成 Temporal，实际生产环境的使用仍受限于支持方面的差异，尤其是 Safari 浏览器和移动端，因为这类场景的功能迭代通常滞后更明显。
GitHub和标准追踪平台的动态也反映了社区反应。Temporal 提案目前仍处于 Stage 3 阶段，但其仓库已开始追踪推进至Stage 4的剩余工作，一旦达成，该 API 将正式纳入 ECMAScript 标准。
对于迁移策略，多数团队可能会渐进式采用 Temporal。提案的官方文档是理解其类型模型和设计意图的起点，而MDN则提供了最易上手的日常 API 供参考。
Temporal 的到来也改变了日期处理工具的竞争格局。在需要跨浏览器支持的场景下，Luxon、date-fns、Day.js以及现已基本成为遗留项目的Moment.js仍会发挥作用。但长远来看，这些库可能会逐步转向便捷封装和定制化格式化的方向，而非继续填补语言层面的基础功能缺口。
Temporal 是由负责 ECMAScript 标准的 TC39 委员会研发的现代化日期时间 API 提案。它提供了一套完整的类型体系，用于处理日期、时间、时区和日历系统，从根本上解决了 JavaScript 遗留Date对象的缺陷。该 API 采用不可变值类型、显式时区处理，并支持多日历系统，非常适合国际化应用的开发。
查看英文原文：Chrome 144 Ships Temporal API: Advancing JavaScript Date/Time Standardisation
