JavaScriptの時間問題を解決した9年の歩み、Temporal

 (bloomberg.github.io)
13 ポイント 投稿者 GN⁺ 2026-03-12 | 7件のコメント | WhatsAppで共有
  • JavaScriptの Dateオブジェクトの限界を根本から置き換える 新しい標準 Temporal API が、9年にわたる開発の末に ECMAScript Stage 4 に到達
  • Temporalは 不変（immutable）型、明示的なタイムゾーン・カレンダー対応、ナノ秒単位の精度 を提供し、既存のDateの曖昧さや誤りを取り除く
  • Bloomberg, Igalia, Microsoft, Google, Mozilla など多様な組織が協力して仕様設計と実装を進め、Rustベースの共通ライブラリ temporal_rs により複数エンジンでの協業を実現
  • Temporalは ZonedDateTime, Instant, PlainDate/Time, Duration など細分化された型を通じて、時間演算と国際化カレンダー処理を正確に支援
  • 30年にわたる問題を解決したこの標準は、JavaScriptエコシステムにおける協業とオープンイノベーションの成功事例 と評価されている

JavaScriptの時間処理の問題とTemporalの登場

  • 既存の Dateオブジェクト は1995年のJavaのDateをそのまま移植したもので、可変性、整合しない月計算、曖昧なパース などにより、数十年にわたってバグの原因となってきた
    • 例: setMonth 使用時の月末計算エラー、ISO風文字列のパース結果がブラウザごとに不一致
  • 2010年代以降、Webアプリケーションが複雑化するにつれてDateの限界が深刻化
  • 開発者は Moment.js などの外部ライブラリで問題を補ってきたが、バンドルサイズの増加と保守負担 が発生
  • 2017年、Maggie Johnson-Pint がTC39に Temporal提案 を提出し、標準化の議論が始まった

TC39と産業界の協業

  • Temporalは2018年の Stage 1 から出発し、9年をかけて Stage 4（標準化） に到達
  • Bloomberg は大規模なJavaScript環境におけるタイムゾーンと精度の問題を解決するため、積極的に参加
    • 要件: ユーザー定義タイムゾーン、IANAベースの歴史的タイムゾーンの正確性、ナノ秒単位の精度
  • Igalia, Microsoft, Google, Mozilla などと協力し、仕様設計と実装を推進
  • Philipp Dunkel, Ujjwal Sharma, Philip Chimento, Shane Carr, Justin Grant など多くのエンジニアがチャンピオンとして参加

Temporalの主要な型と機能

  • Temporal.ZonedDateTime: 明示的なタイムゾーン・カレンダー・DST補正を含む不変の日時表現
    • 例: ロンドンのDST切り替え時に 01:30 が存在しない場合、自動的に 02:30 に補正
  • Temporal.Instant: タイムゾーンやカレンダーを持たない絶対時点の表現で、ナノ秒単位の精度 に対応
    • 同じ時点を複数のタイムゾーンに変換可能
  • PlainDate / PlainTime / PlainDateTime / PlainYearMonth / PlainMonthDay: タイムゾーンを持たない「壁時計型」の型
    • 単純な日付・時刻の表示や計算に適する
  • Temporal.Duration: 時間間隔を表現し、さまざまな単位への変換が可能 (total({ unit: "second" }))
  • カレンダー対応: ヘブライ暦などグレゴリオ暦以外の暦の計算も正確に実行

実装と標準化の過程

  • Temporalは ECMAScript史上最大級の仕様追加 であり、約 4,500件のテストケース を含む
  • Rustベースの共通実装 temporal_rs が開発され、V8, Boa など複数のエンジンが共同利用
    • 利点: 参入障壁の低下、長期保守の容易さ、コード品質の向上
  • 2024〜2025年の間に temporal_rs は100%のテストを通過し、複数エンジン協業の成功事例として評価されている

対応状況と今後の課題

  • Temporalはすでに Firefox 139, Chrome/Edge 144, TypeScript 6.0 Beta で対応
    • Safariはテクノロジープレビュー段階、Node.js 26は今後対応予定
  • 今後の課題は Web APIとの統合
    • 例: <input type="date"> などのフォーム要素で Temporal 型をサポート
    • DOMHighResTimeStamp の代替可能性も検討中（Temporal.Now.instant() の活用例を提示）

協業とオープンイノベーションの成果

  • Temporalは 9年にわたる複数組織の協業 を通じて完成した標準であり、
    • Microsoft, Google, Mozilla, Bloomberg, Igalia, Boa など多様な主体が参加
  • temporal_rs は 共有インフラモデル の成功事例であり、
    • 重複実装コストの削減、一貫性の向上、イノベーションの加速を実証
  • Temporalは単なるAPI改善にとどまらず、JavaScriptコミュニティが長期的な技術的負債を解消した協力の証 と評価されている
  • 30年を経て、JavaScriptは 現代的な日付・時刻API を手に入れた

関連記事

7件のコメント

 
jeeeyul 2026-03-12

時間計算の複雑さは、形式の問題よりも、人類の哲学や天文学の精密さ、そして文化に由来する部分のほうがはるかに大きいです。計算自体は long だけでも簡単です。タイムラインには歴史的に 1 + 1 が 2 ではない特異な区間が定められている場所が多く、太陽と地表の角度など、場所ごとに異なる周易のような暦法に由来する部分が大きいです。このような場合でも、韓国の太陽太陰暦が議論されたことは一度もありません。

そして、それは韓国天文研究院が 決めます。
 
tsboard 2026-03-12

ついに！ うれしい！！
 
shakespeares 2026-03-12

ついに!!
 
roxie 2026-03-12

ZonedDateTime...？ まさか君は..！
 
sea715 2026-03-12

ついに
 
click 2026-03-12

C の time.h -> Java の java.util.Date -> js の Date

Java の joda-time -> JSR 310 -> java.time
-> moment.js -> js Temporal

こういう流れなんですね
 
GN⁺ 2026-03-12
Hacker Newsのコメント
  • Temporalが時間管理の複雑さをきちんと扱うよう強制してくれる点が本当に気に入っている
    instantとカレンダーベースのdatetimeを区別するおかげで、Dateでよく起きていたミスをほぼ防げる
    少し冗長ではあるが、午前3時にDSTバグの修正で呼び出されるよりはずっとまし
    • 技術的に言えば、午前3時にDSTバグを直すことになるのは日曜以外ほとんどなさそう
  • 私もPythonでISO8601の日付パース問題にほぼ10年間苦しめられた
    2012年に始まったIssueが最終的に標準ライブラリの解決策として取り込まれた
    関連する議論はこのGoogle Groupsスレッドで見られる
    • 心から感謝している。fromisoformat以外の方法で日付をパースするのは、今ではあまりに直感的でないと感じる
      以前はciso8601を使っていたが、標準に入ってからはずっと単純で安定している
  • FirefoxがTemporalを仕様段階で実装できたのはAndré Bargull（Anba）のおかげだが、
    彼が実はボランティアとして一人ですべてを実装したという点が特に印象的だ
  • Temporalは大きな前進だが、それでもAPIはあまり好きではない
    私はクライアントとサーバーの間でコードを共有するので、データとロジックを厳密に分離したい
    すべてのデータを純粋なJSONのまま保ってシリアライズ／デシリアライズを簡単にしたいのだが、Temporalオブジェクトは関数プロパティを持つクラスインスタンスなので扱いづらい
    date-fnsのように、データ専用オブジェクトに純粋関数を適用する方式のほうが良いと思う
    • これは意図された設計だ。Temporal型はシリアライズ可能だが、JSON.parseで自動復元はされない
      開発者がISO文字列から正しいオブジェクトを自分で再構築する必要がある
      自動化すると誤った型を扱うリスクがある
      ドキュメントのTemporal.Instant reviverの例が参考になる
    • 私も同じ問題によく遭遇する。JSON.parse/stringifyでプロトタイプが失われるのはよくあるIssueだ
      だがTemporalチームの選択は正しいと思う。日付・時間ロジックでは、単純なデータ+関数アプローチより型安全性のほうが重要だ
      オブジェクトに演算を結びつければ、PlainDateが誤ってZonedDateTimeとして扱われるのを防げる
      tRPCのような場所では、境界でTemporal.from()とtoString()を変換する薄いレイヤーを追加するだけで十分だ
      少し面倒ではあるが、型安全性を捨てるよりはよいと思う
    • 実際、JavaScriptのDateインスタンスも同じ問題を抱えている
      Date.toJSONはあるが、JSONパース時には文字列を再びDateに変換しなければならない
      Temporalも同様で、date-fnsも結局はネイティブのDateインスタンスを扱っている
    • すべてのTemporalオブジェクトは.toString()とTemporal.from()で簡単にシリアライズ／デシリアライズできる
    • JSON.parseが自動的にTemporalオブジェクトを生成するよう変更するのはやりすぎだと思う
      Dateと同じく 
      serialize: instant.toJSON()
deserialize: Temporal.Instant.from(jsonDate)
      このように明示的に処理するのが正しい
  • Temporalが承認されて本当にうれしい
    長いあいだ尽力したすべてのチャンピオンたちに祝意を表したい
    この数年間、temporal_rsに取り組めて楽しかった
  • Javaの時間API改善の歩み（Joda-Time → JSR 310 → Java 8）にも触れていたら面白かったと思う
    JavaScriptの急進的な提案が2018年に出たので、Javaのアプローチがある程度影響したのかも気になる
    • JodaがMoment.jsに影響を与え、それがさらにTC39の議論に反映されたと見るのが妥当だ
      TC39は他言語の先例を参考にしつつ、JavaScriptに最適化された方向で合意した
      今回のAPIは、9年にわたってJSの専門家たちが設計した中で最も完成度の高い実装だと思う
    • その通り、JavaScriptもJavaから出来の悪いDateを持ってきていた
      関連する話はこのHNスレッドでも見られる
  • 「Mocha時代にKen SmithがJavaのDateコードをCへ移植した」という話は面白い
    なぜならJavaのutil.Date自体が、ほぼCのtime.h APIの移植だったからだ
  • SafariがTemporalを部分サポートしているのを見て笑ってしまった
    今やSafariはIEの精神的後継者になったようだ
    • Safariは新機能の導入が遅いが、それでも着実に実装を進めている
      IEの問題は遅さではなく、支配的な地位の上で止まっていたことだった
      今はChromeが帝国の座にあり、むしろSafariとFirefoxのほうが必要だ
      Chrome専用サイトが増えていることこそ本当の問題だ
    • 2026年になってもモバイルSafariにネイティブの日付ピッカーがない気がする
  • Temporalにinterval型があればよかったのにと思う 
    const D = new Temporal()
const t = new Interval({minutes:5})
const v = D.add(t)
    • それはDurationだ 
      const D = Temporal.PlainDate.from("2020-06-16");
const t = Temporal.Duration.from({ day: 1 });
const v = D.add(t) // 2020-06-17
      MDNドキュメント参照
    • そう、それはDurationと呼ぶ
  • このために9年間、1倍速で時間旅行してくれたチームに感謝する