LASSIC Media らしくメディア
タイムゾーンとUTCとは？日時設計の基本を解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
複数の国や地域を対象とするシステムを設計していると、「タイムゾーン」の扱いをめぐって思わぬ手戻りが発生することがあります。日本国内向けのサービスだけを想定していたつもりが、海外拠点のスタッフが利用するようになったり、クラウドサーバーのリージョンを海外に置いたりした途端、日時のずれに気づくというケースは珍しくないものです。原因の多くは、設計の初期段階でタイムゾーンとUTC（協定世界時）の扱いを整理しないまま実装を進めてしまうことにあります。
本記事では、タイムゾーンとUTCの基本的な定義から、日時の扱いでトラブルが起きやすい理由、そしてシステムの日時設計における基本方針までを、システムの企画・設計に携わる法人担当者向けに整理します。特定の製品やライブラリの優劣比較には立ち入らず、押さえておきたい考え方の骨格に焦点を当てます。
この記事のポイント
- UTC（協定世界時）は世界共通の基準時刻で、各地のローカル時刻はUTCからのオフセット（+09:00など）で表されます。
- 日時のトラブルは、サーバーとクライアントのタイムゾーン相違・サマータイム・IANA tzデータベースの更新など、複数の要因が重なって起こりやすいものです。
- 保存はUTCで統一し、表示時にローカル変換する設計を基本方針にすると、システム間の連携でのずれを抑えやすくなります。
タイムゾーンとUTCとは何か
タイムゾーンとUTCの関係を整理するところから始めましょう。両者の定義があいまいなまま設計を進めると、後工程での認識のずれにつながりやすいためです。
UTC・GMTと協定世界時という基準
UTC（Coordinated Universal Time、協定世界時）は、世界各地の時刻を揃えるための基準となる時刻です。かつてはGMT（グリニッジ標準時）が国際的な基準として用いられていましたが、現在はセシウム原子時計を基にした、より精度の高いUTCが実務上の基準になっています。両者は秒単位ではわずかに異なる場合があるものの、日常の業務やシステム設計においてはほぼ同じものとして扱われることが多いといえます。
ローカル時刻とオフセットの考え方
各地域のローカル時刻は、UTCからどれだけずれているかを示す「オフセット」で表現されます。日本標準時（JST）はUTC+09:00、つまりUTCより9時間進んだ時刻です。ニューヨークやロンドンなど、地域によってオフセットは異なり、同じ夏でもサマータイムの有無によって数値が変わる地域もあります。システムが日時を扱う際には、この「どの地域の、どのオフセットにおける時刻か」という情報が欠けていないかを確認することが出発点になります。
混同されやすい概念に「タイムゾーン名」と「オフセット」の違いがあります。オフセットはUTCとの時間差そのものを指す数値である一方、タイムゾーン名（Asia/Tokyoなど、地域名を基にしたIANA形式が一般的です）は、その地域で適用される規則一式を指すものです。地域名の形式でタイムゾーンを保持しておくと、サマータイムの切り替えや将来の規則変更にもシステム側で追従しやすくなる、という利点があります。単純なオフセット値だけを保持する設計では、規則が変わった際に過去のデータの解釈がずれる可能性が残る点には注意が必要でしょう。
なぜ日時の扱いでトラブルが起きるのか
タイムゾーンにまつわるトラブルは、一つの原因だけでなく、複数の要因が重なって表面化する傾向があります。代表的な要因を見ていきましょう。
サーバーとクライアントのタイムゾーン相違
クラウド環境のサーバーはUTCで動作していることが多い一方、開発者の手元の端末や利用者のブラウザはローカルのタイムゾーンで動作しています。この前提を意識しないまま日時を受け渡すと、サーバー側では「9時間ずれた時刻」として記録されたり、逆に表示側で二重に変換してしまったりする不具合が起こりがちです。開発チーム内で「どの層がどのタイムゾーンで日時を扱っているか」を共有できていないことが、根本的な原因になっているケースは少なくありません。
サマータイム（DST）という変動要因
一部の国や地域では、季節によって時刻を1時間ずらすサマータイム（Daylight Saving Time、DST）を採用しています。同じタイムゾーン名であっても、時期によってUTCからのオフセットが変わるため、「固定のオフセットとして扱ってよい地域」と「季節によって変わる地域」を区別しないまま設計すると、特定の時期だけ日時がずれるという厄介な不具合につながります。
うるう秒とIANA tzデータベースの更新
地球の自転速度のわずかなずれを補正するため、不定期に「うるう秒」が挿入されることがあります。頻度は高くないものの、時刻計算にシビアなシステムでは考慮が必要になる場面があるでしょう。また、各国のタイムゾーンやサマータイムの規則は法改正などによって変更されることがあり、この情報を集約したものがIANA tzデータベース（tz database、Olsonデータベースとも呼ばれます）にあたります。OSやミドルウェアが参照するこのデータベースが古いままだと、法改正後の新しい規則に沿わない日時計算をしてしまう恐れがあるため、定期的な更新の仕組みを持っておくことが望ましいところです。
システムでの日時設計の基本方針
ここまで見てきたトラブルの多くは、設計段階で一貫した方針を定めておくことである程度防げるものです。基本となる考え方を整理します。
保存はUTCで統一し、表示時にローカル変換する
もっとも基本となる方針は、システム内部での日時の保存・処理はUTCに統一し、利用者への表示や入力の受け取りの際にだけローカルのタイムゾーンへ変換するというものです。この原則を徹底しておくと、複数の地域にまたがるシステムであっても、内部のロジックはタイムゾーンを意識せずに日時の前後関係や差分を計算できるようになります。表示層だけがタイムゾーンを扱う責任を持つ、という役割分担が設計の軸になるでしょう。
データベースのTIMESTAMP型の扱い
データベースを設計する際は、使用しているTIMESTAMP型がタイムゾーン情報を保持する型なのか、単なる日時の値としてタイムゾーン情報を持たない型なのかを確認しておく必要があります。タイムゾーン情報を持たない型でUTCを保存する運用にする場合は、「この列の値はUTCである」という前提をアプリケーション側の実装やドキュメントで明示しておかないと、後から参照する担当者がローカル時刻と誤認するリスクが残ります。
APIでの日時表現はISO 8601 / RFC 3339
システム間でAPI連携を行う際の日時表現には、ISO 8601形式、その中でも実装しやすいプロファイルとして定義されたRFC 3339形式が広く使われています。「2026-07-25T09:00:00+09:00」のようにオフセットを明示した形式で受け渡すことで、受け取り側がタイムゾーンを推測する必要がなくなり、解釈のずれを防ぎやすくなります。UTCであることを明示したい場合は、オフセット部分を「Z」と表記する書き方も一般的でしょう。
| 観点 | ありがちな実装 | 基本方針として推奨される設計 |
|---|---|---|
| 保存する時刻の基準 | サーバーのローカル時刻のまま保存する | UTCに正規化して保存し、内部処理を統一する |
| DBの型選択 | タイムゾーン情報のない型を無自覚に使う | 型の性質を把握し、UTC運用である前提を明示する |
| API・外部連携での表現 | 独自形式やオフセット省略の文字列 | ISO 8601 / RFC 3339形式でオフセットを明示する |
| ログ出力の時刻基準 | 出力先ごとにローカル時刻とUTCが混在する | UTC基準に統一し、参照時にローカルへ変換する |
対比表のとおり、いずれの観点にも共通しているのは「内部はUTCで統一し、人が読む場面でだけローカルに変換する」という考え方です。次の図は、この基本方針をデータの流れとして示したものです。
よくある実装上の注意点
基本方針を理解していても、実装の細部でつまずくポイントがいくつかあります。ここでは代表的な注意点を整理しておきましょう。
文字列としての日時の受け渡し
日時を文字列として扱う場面では、フォーマットの取り決めが曖昧だと解釈の食い違いが起こりやすいものです。「2026/07/25 9:00」のような形式は、月と日の並び順や12時間表記か24時間表記かが伝わりにくく、タイムゾーンの情報も含まれていません。システム間でやり取りする日時は、オフセットまで含めたISO 8601 / RFC 3339形式の文字列に統一しておくと、受け取った側での解釈違いを防ぎやすくなります。
特に注意したいのが、スプレッドシートやCSVを経由したデータ連携です。表計算ソフトの日時セルは、環境設定や書式によって見た目の表記が変わる場合があり、タイムゾーン情報を持たない文字列のまま別システムへ取り込むと、意図しないローカル時刻として解釈されるおそれがあります。人手を介したファイル連携が残る業務フローでは、出力するテンプレート側でオフセット付きの表記を固定しておくと、取り込み側での誤解釈を防ぎやすいでしょう。
タイムゾーン変換漏れという落とし穴
保存はUTCで統一する方針を決めていても、実装の一部で変換を忘れてしまうと、そこだけ日時がずれるという不具合につながります。特に、バッチ処理やレポート出力、外部システムとの連携部分など、画面表示以外の経路は見落とされやすい箇所です。「この処理はどのタイムゾーンの値を前提としているか」を、コードのコメントや設計書に明記しておく運用が、変換漏れを減らす一助になるでしょう。
ログの時刻基準を統一する
障害調査の際にログを突き合わせる場面では、複数のサーバーやサービスのログがそれぞれ異なるタイムゾーンで記録されていると、時系列の整理に手間がかかってしまいます。ログの出力はUTC基準に統一しておき、必要に応じて閲覧側でローカル時刻に変換する運用にしておくと、複数のログを横断して調査する際の負担を抑えやすくなります。
まとめ：保存はUTC、表示はローカルという原則
本記事では、タイムゾーンとUTCの基本的な定義から、サーバーとクライアントのタイムゾーン相違・サマータイム・IANA tzデータベースの更新といった日時トラブルの要因、そしてシステム設計における基本方針までを整理しました。内部の保存・処理はUTCに統一し、表示や入力の受け取りの際にだけローカルへ変換するという原則が、設計の軸になります。
データベースのTIMESTAMP型の扱いやAPIでの日時表現、ログの時刻基準といった実装レベルの細部まで一貫した方針を通しておくと、複数の地域やシステムにまたがるサービスであっても、日時にまつわる不具合を抑えた設計につながりやすくなります。自社のシステムが現状どのような日時設計になっているかを、この機会に棚卸ししてみてはいかがでしょうか。
よくある質問
UTCとGMTは同じものと考えてよいですか。
実務上はほぼ同じものとして扱われることが多いのですが、厳密には別の基準です。GMTはグリニッジ天文台の天体観測に基づく時刻であるのに対し、UTCは原子時計を基にした基準時刻で、現在はUTCが国際的な標準として用いられています。システム設計の文脈では、UTCを基準として扱う考え方で問題ないでしょう。
日時はローカル時刻で保存してはいけませんか。
禁止されているわけではありませんが、複数の地域やタイムゾーンをまたぐ可能性があるシステムでは、ローカル時刻のまま保存すると後から不整合が生じやすくなります。国内の単一拠点だけで完結し、将来的にも拡張予定がないと明確に分かっている場合を除き、保存はUTCに統一しておくと後々の手戻りを抑えやすくなります。
サマータイムを採用していない日本のシステムでも意識する必要がありますか。
日本国内向けのシステムであっても、外部の海外サービスと連携したり、海外拠点の利用者が増えたりする可能性があるなら、意識しておく価値はあります。設計の初期段階でUTC基準を前提にしておけば、後からサマータイムを採用する地域が対象に加わっても、変更の範囲を表示層に留めやすくなります。
IANA tzデータベースはどのくらいの頻度で更新すればよいですか。
一律の頻度が定められているわけではなく、各国の法改正などに応じて不定期に更新版が公開されます。OSやミドルウェアのアップデートに追従する運用にしておき、大きな法改正のニュースがあった際には反映状況を確認する、という運用が現実的です。
ISO 8601とRFC 3339はどう違いますか。
RFC 3339は、ISO 8601が定める幅広い表記のうち、インターネット上での利用を想定して表記のゆれを絞り込んだプロファイルという位置づけです。API連携などの実装場面では、表記の自由度が少ないRFC 3339に沿っておくと、送受信双方での解釈違いを防ぎやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IANA「Time Zone Database」（https://www.iana.org/time-zones）
- *2 出典：RFC 3339「Date and Time on the Internet: Timestamps」（https://www.rfc-editor.org/rfc/rfc3339）
- *3 出典：情報通信研究機構（NICT）「日本標準時プロジェクト」（https://www.nict.go.jp/JST/ ）
