Chrome 144からTemporal APIのサポートが追加され、Webにモダンな日付と時刻のAPIが導入された。これは長年にわたりTC39で検討されてきた提案が、初めて安定版のChromeに搭載されたことを意味する。この変更はChromeのリリースブログで強調され、Temporalは長年批判されてきたJavaScriptのDateオブジェクトに代わるモダンな選択肢であると位置付けられている。
グローバルなTemporal名前空間として公開されるTemporalは、不明確なパース規則、扱いにくいタイムゾーン処理、変更可能な日付演算といった既知の問題を解決することを目的としている。用途ごとに異なる型を提供し、既存の値を変更するのではなく新しい値を返す設計だ。MDNはTemporalをDateの完全な置き換えと説明しており、組み込みのタイムゾーンとカレンダー、壁時計変換、演算、フォーマット機能を備えているとしている。
最大の実務的利点の一つは、開発者がタイムゾーンや時刻を誤って混入させることなく日付を表現できる点だ。例えば次のようになる。
const start = Temporal.PlainDate.from('2026-02-13'); const end = start.add({ days: 7 }); タイムゾーンが重要な場合、APIはそれを明示的に扱う。Dateを文字列にフォーマットし、暗黙の変換が途中で起きていないことを祈る代わりに、ZonedDateTimeはタイムゾーンを値の中に保持する。
const now = Temporal.Now.zonedDateTimeISO('Europe/London'); const later = now.add({ hours: 2 }); オンライン上の反応は、安堵と導入への不安が入り混じったものとなっている。人気のRedditスレッドでは、基本的な日付処理のためにサードパーティーライブラリを捨てられる可能性を開発者たちが歓迎した。あるコメント投稿者は、ここに至るまでに長い時間がかかったと述べ、Dateの落とし穴を指摘しつつ、「日付処理のように根本的な機能のためにライブラリを同梱しなければならない状況は常に煩わしかった」と語っている。
一方で、Chromeに搭載されたとはいえ、すべてのブラウザでのサポート不足やフレームワーク、ライブラリ側の対応状況により、実際の利用には遅れが生じる可能性がある。この点についてRedditのスレッドでは次のようなコメントが紹介されている。
Chromeで提供が始まった今、特にスケジューリングやアナリティクスに大きく依存するアプリにおいて、ライブラリやフレームワークがどれほど早く採用を始めるのか気になります。
最近のMediumの記事はこの点をさらに掘り下げ、ChromeがTemporalを搭載したにもかかわらず、実運用での利用は依然として制約を受けていると主張している。特にSafariやモバイル環境では機能の遅れが顕著であり、サポートギャップが大きな要因だとしている。
GitHubや標準化の進捗追跡も反応の一部となっている。Temporal提案は依然としてStage 3にあるが、リポジトリではStage 4到達を目指した残作業の管理が進められている。Stage 4に到達すれば、ECMAScriptの一部としてAPIが完全に標準化される。
移行に関しては、多くのチームがTemporalを段階的に採用する可能性が高い。提案者自身のドキュメントは型モデルや想定される利用パターンを理解するための出発点となり、日常的なAPI仕様の参照としては現時点でMDNがもっとも利用しやすい情報源である。
Temporalの登場は、日付処理ツールを巡る競争環境にも変化をもたらす。Luxon、date-fns、Day.js、そして現在ではレガシー色の強いMoment.jsといったライブラリは、クロスブラウザ対応が必要な場面では引き続き重要である。しかし時間の経過とともに、言語レベルの根本的な欠落を補う役割から、利便性の高いラッパーや特定の好みに応じたフォーマット成形へと重心を移していく可能性がある。
Temporalは、ECMAScriptを管轄する標準化団体TC39委員会によって開発されたモダンな日付と時刻のAPI提案である。日付、時刻、タイムゾーン、カレンダーシステムを扱うための包括的な型群を提供し、JavaScriptの従来のDateオブジェクトが抱えてきた根本的問題に対処する。APIは不変（イミュータブル）な値型、明示的なタイムゾーン処理、複数のカレンダーシステムのサポートを備えており、国際化されたアプリケーションに適した設計である。