Temporal：修復 JavaScript 時間處理問題的九年征程

背景

這篇文章由 Bloomberg 工程師 Jason Williams 撰寫，詳述了 JavaScript 全新日期與時間 API「Temporal」長達九年的開發歷程。由於現行的 Date 物件是 1995 年為了趕工而直接移植 Java 早期設計的產物，長期存在可變性、月份計算混亂及時區處理模糊等缺陷，Temporal 的出現旨在提供一個現代、不可變且功能完備的原生解決方案。

社群觀點

在 Hacker News 的討論中，開發者社群對於 Temporal 的到來普遍抱持高度期待與正面評價。許多留言者認為，Temporal 最具價值的設計決策在於其「不可變性」（Immutability）。過去數十年來，JavaScript 開發者深受 Date 物件的副作用所苦，常因誤用 setMonth 或 setHours 等方法導致原始物件被意外修改，進而引發難以追蹤的臭蟲。Temporal 透過強制回傳新物件而非修改現有物件，從根本上解決了這類共享狀態導致的錯誤。此外，Temporal 要求開發者必須在 ZonedDateTime 與 PlainDate 之間做出明確選擇，這種強迫處理時區的設計，也被視為修復 Date 建構函式隱含本地時區轉換問題的關鍵。

儘管不可變性獲得一致好評，社群中也有關於效能與實作細節的討論。部分開發者指出，雖然在 React 等現代框架中，不可變性已成為主流共識，但在極端追求效能的場景下，可變的雜湊映射（Mutable Hash Map）有時仍比不可變方案更具優勢。此外，也有人提到 React 本身僅檢查物件引用（Reference）而非深層內容，這使得不可變資料在框架整合上仍有其複雜性。

另一個討論焦點在於 Temporal 與其他語言 API 的傳承關係。有留言者好奇 Temporal 是否受到 Java 8 推出的 JSR 310 或 Joda-Time 的啟發，畢竟 Java 早已在 2014 年完成了自身的日期 API 改革。對此，參與 TC39 標準制定的專家回應，雖然委員會在設計時會廣泛參考其他語言的既有成果，但 Temporal 的設計路徑更多是受到 JavaScript 生態系內部（如 Moment.js）的經驗所驅動。TC39 的目標是建立一個最適合 JavaScript 環境、且能解決過去三十年累積痛點的完整實作，而非單純模仿其他語言。

最後，開發者們對於 Temporal 的落地進度展現了迫切感。雖然 Node.js 與各大瀏覽器正逐步導入，但社群仍期待它能早日成為伺服器端運作環境的標配，以徹底擺脫對 Moment.js 等大型第三方函式庫的依賴，進而優化前端資源包的大小。

延伸閱讀

• temporal_rs：留言中提到的 Temporal Rust 實作版本，對於關注底層效能與跨語言實作的開發者具有參考價值。
• JSR 310 / Joda-Time：Java 社群針對日期時間處理的標準化成果，是理解現代日期 API 設計哲學的重要背景知識。