プログラミングでの UTC 変換 - タイムゾーン処理の正しい実装パターン

保存は UTC、表示はローカル - 鉄則の理由

タイムゾーン処理の最も重要な原則は「データベースには UTC で保存し、ユーザーへの表示時にローカルタイムに変換する」ことです。この原則を守らないシステムは、サマータイムの切り替え時にデータの不整合が発生し、国際展開時に破綻します。

UTC で保存する理由は明確です。UTC にはサマータイムがなく、常に単調増加する時刻系です。ローカルタイムで保存すると、サマータイム終了時に「同じ時刻が 2 回出現する」問題が発生します。たとえばニューヨークで 11 月第 1 日曜日の午前 1:30 は、EDT (UTC-4) と EST (UTC-5) の両方で存在するため、どちらの 1:30 なのか区別できなくなります。

ISO 8601 形式とタイムゾーン情報の保持

日時データを文字列として扱う場合、ISO 8601 形式 (例: 2026-05-15T07:00:00Z) を使用します。末尾の Z は UTC を意味し、+09:00 のようなオフセット表記でローカルタイムを表現することもできます。重要なのは、タイムゾーン情報を必ず含めることです。2026-05-15T16:00:00 のようにオフセットのない文字列は、どのタイムゾーンの時刻なのか判別できず、バグの温床になります。

データベースのカラム型としては、PostgreSQL の TIMESTAMP WITH TIME ZONE (timestamptz)、MySQL の DATETIME に UTC を明示的に設定する方式が推奨されます。TIMESTAMP WITHOUT TIME ZONE は、アプリケーション側で UTC であることを暗黙的に仮定する必要があり、チーム内の認識齟齬によるバグが発生しやすくなります。

JavaScript/TypeScript での実装パターン

JavaScript の Date オブジェクトは内部的に UTC のミリ秒タイムスタンプを保持しており、toString() や toLocaleString() で表示する際にブラウザのローカルタイムゾーンに変換されます。サーバーサイド (Node.js) では環境変数 TZ がシステムのタイムゾーンを決定するため、本番環境では TZ=UTC を設定しておくことが安全です。

Intl.DateTimeFormat API を使えば、任意のタイムゾーンでの表示が可能です。timeZone オプションに IANA タイムゾーン名 (例: America/New_York) を指定することで、サマータイムの切り替えも自動的に処理されます。自前でオフセット計算を実装する必要はなく、むしろ実装すべきではありません。サマータイムのルールは頻繁に変更されるため、OS やランタイムが提供する IANA データベースに委ねるのが正解です。

よくあるタイムゾーン関連のバグ

最も頻発するバグは「日付のみを扱う場面でタイムゾーンを無視する」ケースです。ユーザーの誕生日を 1990-03-15 として保存し、これを new Date('1990-03-15') で解析すると、ブラウザによっては UTC の 0:00 として解釈され、UTC-5 のユーザーには 3 月 14 日と表示されます。日付のみのデータは T12:00:00Z のように正午を指定するか、文字列のまま保持して Date オブジェクトに変換しないのが安全です。

もう一つの典型的なバグは、cron ジョブやスケジュールタスクをローカルタイムで設定することです。サマータイムの切り替え日に、ジョブが 2 回実行されたり (秋の巻き戻し時)、スキップされたり (春の繰り上げ時) します。スケジュールは UTC で定義し、実行結果のログにも UTC タイムスタンプを記録することで、この問題を根本的に回避できます。

タイムゾーン処理のテスト戦略

タイムゾーン処理のテストでは、少なくとも以下のケースをカバーする必要があります。UTC+0 (ロンドン冬季)、正のオフセット (東京 UTC+9)、負のオフセット (ニューヨーク UTC-5)、30 分オフセット (インド UTC+5:30)、サマータイム切り替え前後、日付変更線をまたぐケース、そして年末年始 (年が変わるケース) です。

CI 環境のタイムゾーン設定にも注意が必要です。開発者のローカル環境が UTC+9 で、CI が UTC で動作している場合、ローカルでは通るテストが CI で失敗することがあります。テストコード内で明示的にタイムゾーンを指定するか、テスト対象の関数がタイムゾーンを引数として受け取る設計にすることで、環境依存を排除できます。