JavaScript Temporal: 九年修正时间处理难题
三年前，我负责过一个跨境结算系统，某天财务反馈账单少了整整一小时。排查后发现，代码里用new Date()处理跨时区时间戳，恰逢目标地区切换夏令时，原生 Date 对象在序列化过程中悄悄吞掉了那个不存在的时刻。那一刻我意识到，JavaScript 的时间处理机制就像一颗埋在地下的雷，平时相安无事，一旦涉及复杂业务就会爆炸。这个问题并非个例，而是整个语言设计的历史遗留缺陷。历经九年提案迭代，Temporal API 终于进入 Stage 3 阶段，它不是为了增加新功能，而是为了修正 JavaScript 诞生之初就犯下的错误。
原生 Date 对象的结构性缺陷
JavaScript 的Date对象设计于 1995 年，当时的网络环境简单，时区处理需求远不如今天复杂。如今看来，它的核心问题在于可变性与模糊性。Date实例是可变的，这意味着当你调用setMonth或setHours时，对象本身的状态被修改，这在异步回调或函数传参中极易引发副作用。更严重的是，Date内部存储的是 UTC 时间戳，但在展示时却依赖运行环境的系统时区，这种隐式转换导致同一份代码在不同服务器上跑出不同结果。
举个例子，当我们试图计算两个日期之间的天数差时，原生 API 缺乏直接支持，开发者不得不手动计算毫秒差再换算。如果期间跨越了闰秒或夏令时，简单的毫秒除法就会出错。以下代码展示了原生 Date 在修改月份时的典型陷阱，它会自动调整日期，导致逻辑不可控：
const date = new Date(2023, 0, 31); // 2023 年 1 月 31 日 console.log(date.toDateString()); // 输出：Tue Jan 31 2023 date.setMonth(1); // 试图设置为 2 月 console.log(date.toDateString()); // 输出：Tue Feb 28 2023 (自动变为 28 日，而非报错或保持 31 日) // 这种静默失败在财务计算中是致命的此外，Date的月份是从 0 开始计数的，而日期是从 1 开始，这种不一致性几乎让每个新手都踩过坑。字符串解析也存在严重问题，new Date('2023-01-01')在不同浏览器中可能被解析为本地时间或 UTC 时间，这种不一致性使得后端与前端的时间校验经常失效。我们需要的是一种不可变、显式声明时区、且语义清晰的时间模型，这正是 Temporal 设计的出发点。
Temporal 的不可变设计与类型分离
Temporal 提案的核心哲学是“不可变”与“类型分离”。在 Temporal 模型中，时间对象一旦创建就无法修改，任何操作都会返回一个新的实例。这消除了副作用，使得时间数据在多线程或异步流中安全传递。更重要的是，Temporal 将日期、时间、时区拆分为不同的类型，开发者必须显式决定自己需要的是“墙钟时间”还是“精确时刻”。
Temporal.PlainDate仅代表日历日期，不带时区信息，适合处理生日、节假日等场景。Temporal.ZonedDateTime则包含时区信息，适合记录交易时间、日志戳等需要精确到瞬间的场景。这种分离强制开发者在编码阶段就思考时间的语义，而不是等到运行时才发现时区错乱。以下是使用 Temporalpolyfill创建不可变日期并进行的安全操作示例：
```javascript import { Temporal } from '@js-temporal/polyfill';
const start = Temporal.PlainDate.from('2023-01-31'); const next = start.add({ months: 1 });
console.log(start.toString()); // 输出：2023-01-31 (原对象未变)