AI 摘要：本文详细探讨了 JavaScript 中 Temporal API 的背景、必要性以及其开发进展缓慢的原因。Temporal API 是对现有 Date API 的重大升级，旨在解决其功能不足和不一致的问题，提供更全面的日期和时间处理能力。尽管提案自 2017 年开始已进入 TC39 的第 3 阶段，但由于与现代标准（如 IANA、ISO-8601 等）的复杂互操作性要求，开发耗时近八年。目前，Firefox 已率先实现，Chrome 和 Safari 也在推进中，作者乐观预测其可能在年内正式发布。

1. 什么是 Temporal API？
• Temporal API 是 JavaScript 对 Date API 的 overdue 替代品，旨在提供更现代化的日期和时间处理功能。
• 作者希望其能在今年内正式在浏览器中发布。

2. 为什么需要替换 Date API？
• JavaScript 的 Date API 是 1995 年 Brendan Eich 快速开发时直接从 Java 的 java.util.Date 复制而来，存在诸多缺陷（如 Y2K 问题）。
• Java 早已废弃并更新了其 Date API，而 JavaScript 却沿用了 30 年，导致功能不足（例如缺乏对持续时间、间隔等的支持）和不一致性。
• 现有解决方案依赖第三方库，这些库因需要传输时区和本地化数据而变得臃肿。
• Temporal 作为一个命名空间，将原生支持时间戳、持续时间、间隔和时区管理，极大增强浏览器的日期时间能力。

3. 为什么 Temporal API 开发耗时如此之长？
• Temporal API 自 2017 年提出，至今已耗时八年，仍处于 TC39 的第 3 阶段（共 4 阶段）。
• 主要延迟原因并非功能范围，而是与现代 web 和计算标准的互操作性需求：
• 时区字符串基于 IANA Time Zone Database。
• 时间戳字符串基于 RFC9557（RFC3339 的更新，2024 年 4 月通过）。
• 持续时间字符串基于 ISO-8601 标准。
• 这些标准的协调（如 IETF 对 RFC3339 的扩展）耗费了大量时间。
• 此外，Temporal 与 ECMA-402 国际化 API（例如 Intl.DateTimeFormat）的数据来源（如 Unicode CLDR）也需整合，进一步减少对大型库的依赖。
• 2024 年 6 月，为加速发布，Temporal 范围被缩减，自定义日历和时区功能被移除，但未来可能通过 Temporal v2 提案恢复。
• 当前进展：
• Firefox 已于 139 版本（2023 年 5 月 27 日）实现。
• Chrome V8 部分实现了 Temporal.Instant，基于 Rust 库 temporal_rs。
• Safari 的 JavaScriptCore 也在开发中。
• 进入第 4 阶段需“两个兼容实现通过验收测试”，目前仍未达成，但作者乐观预测年内可能实现。
• 当前用户可通过 Firefox 或 Temporal polyfill 进行测试。

The Computus Engine

When can I use Temporal?

TC39 has had a Temporal API proposal in the works since 2017. It's currently at stage 3 (of 4). So this begs an obvious question... If Brendan Eich can invent all of JavaScript in 10 days, why has it taken eight years to replace the Date API?

Lets back up