从Chrome 144开始，浏览器开始支持Temporal API。这一功能的加入为网页应用带来了现代化的日期和时间处理机制，同时也标志着首个正式发布的Chrome版本实现了长期讨论中的TC39提案。Chrome的官方发布日志中特别强调了这一变化，认为Temporal API是针对JavaScript长期以来备受诟病的Date对象而推出的现代化替代方案。
Temporal API被定义为全局Temporal命名空间，它通过为不同的操作提供专门的类型，并返回新的值而非修改现有数据，从而解决了诸如解析规则不明确、时区处理不当以及日期运算容易出错等问题。MDN将其描述为可以完全取代Date的对象，因为它内置了时区、日历功能，同时还支持时钟时间转换、算术运算和格式化操作。
这一变化带来的一个实际好处是：开发者现在可以更加清晰地表示日期，而不会无意中包含时区和具体时间信息。例如：
“`javascript
const start = Temporal.PlainDate.from(‘2026-02-13’);
const end = start.add({ days: 7 });
“`
当时区信息确实很重要时，Temporal API会明确地显示这些信息。与将Date对象转换为字符串并希望转换过程中不会发生隐式转换的做法不同，ZonedDateTime类型会直接在值中包含时区信息：
“`javascript
const now = Temporal.Now.zonedDateTimeISO(‘Europe/London’);
const later = now.add({ hours: 2 });
“`
网友对这一变化的反应既有欣慰，也有一些担忧。在一个非常受欢迎的Reddit帖子中，许多开发者都表示很高兴终于可以不再依赖第三方库来处理日期相关功能了。有评论者指出，长期以来人们一直不得不使用那些专门为日期处理而设计的第三方库，这确实很麻烦。
尽管Temporal API已经在Chrome中正式启用，但由于其他浏览器尚未支持这一功能，再加上许多框架和库也还没有采用它，因此实际应用中可能还会遇到一些延迟。正如有人在Reddit帖子中指出的：
“我很想知道，现在既然Chrome已经开始使用Temporal API了，那些依赖日程安排或数据分析功能的应用程序会多快开始采用它呢？”
一篇发表在Medium上的文章进一步分析了这个问题，作者认为尽管Chrome已经支持Temporal API，但在实际生产环境中，由于其在其他浏览器和移动设备上仍缺乏支持，因此其应用范围仍然会受到限制。
GitHub以及相关标准跟踪工作也是这些应对措施的一部分。该提案目前仍处于第三阶段，但其代码仓库正在记录为达成第四阶段而需要完成的工作；一旦达到第四阶段，该API就能被正式纳入ECMAScript标准体系之中，从而实现其标准化。
在迁移过程中，大多数团队可能会逐步采用Temporal这一技术。要了解该类型的模型及其预期使用方式，该提案的官方文档是一个很好的起点；而MDN则提供了关于日常使用的API细节的最详细参考资料。
Temporal的出现也改变了日期处理工具领域的竞争格局。像Luxon、date-fns、Day.js，以及现已逐渐被淘汰的Moment.js这样的库，在那些需要跨浏览器兼容性的场景中仍然具有重要意义。不过随着时间的推移，这些库的功能可能会更多地转向提供便捷的封装接口或自定义的格式化功能，而不是用来弥补JavaScript语言本身存在的缺陷。
Temporal是由负责制定ECMAScript标准的TC39委员会提出的一套现代日期时间API方案。它为处理日期、时间、时区及日历系统提供了完备的数据类型支持，有效解决了JavaScript传统Date对象所存在的一系列问题。该API支持不可变的数据类型、明确的时区处理机制，并且兼容多种日历系统，因此非常适用于国际化应用开发。