摘要：MDN将其描述为Date对象的完整替代方案，内置支持时区与日历系统、墙上时间（wall clock）转换、算术运算及格式化功能。它提供了一套完整的类型体系，用于处理日期、时间、时区和日历系统，从根本上解决了JavaScript遗留Date对象的缺陷。nbsp;查看英文原文：Chrome 144 Ships Temporal API: Advancing JavaScript Date/Time Standardisation"
自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"
自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上的评论说：
近期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"