加载失败
Temporal 是 TC39（JavaScript 语言标准化委员会）推动、历时多年（近九年）才达成共识的时间 API 提案，目标是修复原生 Date 的模糊语义、可变性与跨时区陷阱。提案引入了明确区分瞬时（Instant）、无时区日历/时间（PlainDate/PlainTime）与带时区时间（ZonedDateTime）等类型，并主张不可变性与显式转换以减少 DST/调度错误。实现层面有浏览器引擎和独立实现（polyfill/temporal_rs/第三方库）协同推进；但现实问题包括浏览器（特别是 Safari/WebKit）支持滞后、时区数据（tzdata）更新依赖平台发行以及 JSON 本身无日期类型导致的序列化权衡。社区讨论因此既庆祝语义上的改进，也在争论可用性、性能与跨进程/跨语言交换的工程实践。
许多评论认为 Temporal 最大的价值在于把“瞬时（instant）”与“日历/墙钟时间（calendar datetime）”语义明确分开，并以不可变类型避免原生 Date 的易错写法。评论里有人提到用 Temporal 后几乎消灭了对旧 Date 的使用、修复了大量生产 bug，并把重复的转换/格式化逻辑抽成库以提高可读性与复用性。多条回复强调，强制显式地选择 PlainDate/Instant/ZonedDateTime 等类型能在调度和跨时区场景里显著减少 DST 和语义混淆的事故。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
很多人指出 Temporal 对象不是纯数据，JSON.stringify 会输出可读字符串但 JSON.parse 不会自动恢复对象原型，必须用 JSON.parse 的 reviver 或在边界层显式调用 Temporal.from/Instant.from 等方法来重建类型。评论讨论了 reviver 的性能问题、tRPC 等传输层可加入 thin transform，以及现有的“JSON pro”方案（如 superjson、devalue、CBOR、Amazon ION）如何作为替代。总体共识是：Temporal 提供了清晰的类型，但跨语言或跨进程交换时仍需额外的约定或库来保证类型安全与性能。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
许多评论抱怨常见调用太冗长，例如将 new Date() 的语义替换为 Temporal.Now.zonedDateTimeISO() 或需通过 Temporal.Now.instant().epochMilliseconds 获取时间戳，而命名风格（PascalCase）也与大多数 JS 风格不同。反对者认为这会阻碍广泛采用、并增加学习成本；支持者则认为这种冗长是有意为之，用来暴露时间类型的细微差别，强迫开发者在选择时区/瞬时/本地时间时更审慎。讨论还提到希望未来能加层便捷别名或语法糖，但当前的设计是为了减少因模糊语义导致的错误。
评论里反复提到实际可用性受限于浏览器与运行时的支持：Chrome 已将 API 推到稳定，Deno 曾在 flag 下提供、后移除 flag；Node 的较新版本（如 26）也在推进，但 Safari/WebKit 实现较慢并导致广泛采用受阻。讨论还指出时区数据（tzdata / IANA 时区数据库）通常由操作系统或浏览器维护，发生政府规则变更时需要通过平台更新来修复时区规则，而不是靠网站端更新 polyfill。为此许多人仍然在短期内依赖 polyfill，但担心在旧平台上的兼容性与长期维护成本。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论回顾了 Temporal 是 TC39 经过多年演进的提案，吸收了其他生态（如 Java 的 Joda-Time / JSR-310、NodaTime 等）的设计理念与教训。实现这套 API 的工程量巨大，一些实现者以志愿者身份完成了在某些引擎（例如 Firefox）上的完整实现并在规范上做了大量修补与迁移工作。社区普遍把这当成一次长期的、多方经验累积后的产物，而非草率设计，因而也难怪耗时多年才达成共识。
关于不同历法（calendar）之间的转换有明显争议和限制：直接从某些非 ISO 日历（如 Buddhist）转换到其他复杂的农历体系（如 Hebrew）会触发错误，因为太阳历与阴阳历之间存在闰月与朔望月的模糊。评论解释了实现团队为避免指数级角落案例而有意限制直接互转，推荐的做法是先显式地转换到 ISO（或使用 withCalendar）再转换为目标历法，从而保持显式性而不是隐式猜测。总体上这是设计上的权衡——更保守但更明确地避免错误转换。
有开发者偏好纯数据 + 纯函数（像 date-fns）以便 JSON 传输和简单序列化，但也有人指出这种“袋装数据+自由函数”容易忘记传入必要上下文（如 calendar、timezone），从而引发细微错误。Temporal 团队选择把操作绑定到对象实例上以借助类型/方法减少误用，评论里提出的折中方案是：在边界处用轻量的转换层或社区库提供函数式封装，以同时兼顾可序列化性与类型安全。讨论还提到 TypeScript 的 structural typing 对这类设计会带来额外考量，但总体认为绑定方法能防止很多隐式错误。
少数评论报告了 polyfill 或早期实现的性能问题，并希望官方引擎实现能进一步优化以满足高性能场景。也有实战者表示已在生产使用 polyfill 且未遇到问题，另有评论提醒 JSON.parse 的 reviver 会对大 JSON 性能产生显著影响。整体讨论倾向于认为语义与正确性优先，但希望主流引擎（V8、SpiderMonkey、WebKit）在实现上进一步提升效率并在未来补上性能差距。
Temporal.PlainDate / PlainTime / Instant / ZonedDateTime（Temporal 类型）: Temporal 将日期/时间分成多种明确类型：Plain 系列表示无时区的日历或时钟数据（如 PlainDate、PlainTime），Instant 表示绝对瞬时点（以 UTC 度量），ZonedDateTime 则在时间上绑定具体时区。这样的拆分旨在避免把不同语义混为一谈，从而减少调度、DST 和时区相关的错误。
tzdata（IANA 时区数据库）: IANA tz database（常称 tzdata）是记录全球时区规则与夏令时变更的权威数据源，操作系统和浏览器通常依赖它来计算本地时间。时区法规改变时，平台需要更新 tzdata 才能保证 Temporal 等库输出与现实一致。
JSON.parse reviver（reviver 回调）: JSON.parse 提供的 reviver 回调允许在反序列化每个键值时自定义转换逻辑，常被用来把 ISO 字符串恢复成 Date 或 Temporal 对象。虽然能实现自动重建，但在大对象上会带来性能开销，并不能解决跨语言互操作性问题。
Temporal.Duration: Temporal.Duration 表示相对时间段（例如 days、hours、minutes、nanoseconds），对应评论中对“Interval”需求的表述。Duration 用于对 Date/Time 对象做加减运算，是表示持续时长的内建类型。