時刻 API の比較 - JavaScript, Python, Java における日時処理ライブラリの選定

JavaScript Temporal API - Date の失敗を正す新標準

JavaScript の Date オブジェクトは 1995 年の設計当初から多くの問題を抱えています。月が 0 始まり (0 = 1 月)、ミュータブル (破壊的変更が可能)、タイムゾーン操作が貧弱、パース動作がブラウザ間で不統一など、実務で踏む地雷が多数あります。Temporal API (TC39 Stage 3) はこれらの問題を根本的に解決する新しい日時 API です。

Temporal の最大の特徴は、用途に応じた複数の型を提供することです。Temporal.Instant (UTC の絶対時刻)、Temporal.ZonedDateTime (タイムゾーン付き日時)、Temporal.PlainDateTime (タイムゾーンなし日時)、Temporal.PlainDate (日付のみ)、Temporal.PlainTime (時刻のみ) が明確に分離されており、「この値にタイムゾーン情報があるのかないのか」が型レベルで保証されます。

Python datetime + zoneinfo - 標準ライブラリの進化

Python の datetime モジュールは「naive (タイムゾーン情報なし)」と「aware (タイムゾーン情報あり)」の 2 種類の datetime オブジェクトを区別します。Python 3.9 で追加された zoneinfo モジュールにより、IANA タイムゾーンデータベースへのアクセスが標準ライブラリだけで可能になり、サードパーティの pytz への依存が不要になりました。

Python の datetime の注意点は、naive と aware の混在です。naive な datetime に対してタイムゾーン変換を行おうとすると TypeError が発生しますが、比較演算では暗黙的に許容される場合があり、バグの原因になります。ベストプラクティスは、システム内のすべての datetime を aware (UTC) で統一し、表示時にのみローカルタイムに変換することです。

Java java.time - JSR 310 の設計哲学

Java 8 で導入された java.time パッケージ (JSR 310) は、Joda-Time の設計者 Stephen Colebourne が主導した API であり、日時処理 API の設計として最も成熟しています。イミュータブル、スレッドセーフ、明確な型分離 (LocalDateTime, ZonedDateTime, Instant, Duration, Period) という原則が徹底されています。

java.time の特筆すべき設計判断は、Duration (時間ベースの量: 秒・ナノ秒) と Period (日付ベースの量: 年・月・日) を明確に分離していることです。「1 か月後」は暦によって 28〜31 日と変動するため、Duration (固定秒数) とは本質的に異なる概念です。この区別を型レベルで強制することで、期間計算のバグを防止しています。

言語横断の共通落とし穴

どの言語でも共通する落とし穴は「日付のみの値をタイムゾーン付きの日時に変換する際の曖昧さ」です。「2026-05-15」という日付を DateTime に変換する場合、どのタイムゾーンの 0:00 を基準にするかで結果が変わります。UTC の 0:00 なのか、ローカルタイムの 0:00 なのかを明示しないと、タイムゾーンによっては日付が 1 日ずれます。

もう一つの共通課題は、文字列パースの寛容さです。「2026-5-15」「2026/05/15」「May 15, 2026」「15.05.2026」など、同じ日付を表す文字列形式は無数にあります。厳密なパース (指定したフォーマットに完全一致しなければエラー) を使い、寛容なパース (推測で解釈) を避けることが、国際化対応のシステムでは鉄則です。

ライブラリ選定と移行の指針

新規プロジェクトでは、各言語の最新標準 API を使うのが最善です。JavaScript は Temporal (ポリフィル経由)、Python は datetime + zoneinfo、Java は java.time です。既存プロジェクトで moment.js や pytz を使っている場合、段階的な移行が推奨されます。新しいコードでは新 API を使い、既存コードは触る機会に順次移行する方針が現実的です。

サードパーティライブラリ (Luxon, date-fns, Arrow, Pendulum) は標準 API の不足を補う場面で有用ですが、依存関係の増加とメンテナンスリスクを伴います。標準 API で実現可能な処理にサードパーティを使うのは避け、相対時刻のフォーマットや複雑な繰り返しパターンの計算など、標準 API では冗長になる処理に限定して使用するのが賢明です。