UTCを日本時間へ直すときは9時間を足します。日本時間のJSTからUTCへ戻すときは9時間を引きます。 たとえばUTCの12時は日本時間の21時です。UTCの15時は日本時間では翌日の0時になるため、時刻だけでなく日付も一緒に確認します。
日本標準時はUTCより9時間進んでいます。この関係はNICTの日本標準時の説明でも確認できます。会議の案内やログの時刻を読むときは、表示が本当にUTCなのかを見るところから始めると、変換を間違えにくくなります。
UTCと日本時間の早見表
UTCの0時から14時台までは同じ日付の日本時間になります。15時以降は翌日です。次の表は左列の日付を基準にしています。
| UTC | 日本時間（JST） | 日付 |
|---|---|---|
| 00:00 | 09:00 | 同じ日 |
| 03:00 | 12:00 | 同じ日 |
| 06:00 | 15:00 | 同じ日 |
| 09:00 | 18:00 | 同じ日 |
| 12:00 | 21:00 | 同じ日 |
| 14:00 | 23:00 | 同じ日 |
| 15:00 | 00:00 | 翌日 |
| 18:00 | 03:00 | 翌日 |
| 21:00 | 06:00 | 翌日 |
| 23:00 | 08:00 | 翌日 |
たとえば「9月18日18時UTCに開始」と書かれていれば、日本では9月19日3時です。9月18日のまま予定へ登録すると一日早くなってしまいます。任意の日付と時刻はタイムゾーン変換ツールでも確認できます。
日本時間からUTCへ戻すと前日になる場合がある
日本時間をUTCへ変換するときは逆方向に計算します。9時間を引いて0時より前になったら、日付を一日前へ戻します。
日本時間 2026-09-18 09:00 → UTC 2026-09-18 00:00
日本時間 2026-09-18 08:00 → UTC 2026-09-17 23:00
日本時間 2026-09-18 00:30 → UTC 2026-09-17 15:30
「日本の金曜朝に公開したい」という指定をUTCで入力する場合も同じです。時刻欄だけを計算せず、公開日を含めて変換します。月初なら前月末、年初なら前年になることもあります。
末尾のZと+09:00を見れば二重変換を防げる
APIやログでは、日付と時刻の後ろにタイムゾーンの情報が付きます。RFC 3339では Z はUTCを表し、数値のオフセットはUTCとの差を示します。日時表記の仕様で定義されています。
2026-09-18T00:30:00Z
2026-09-18T09:30:00+09:00
上の二つは同じ瞬間です。最初はUTC、二つ目はUTCより9時間進んだ表記なので、そのまま日本時間の9時30分と読めます。+09:00 の時刻へさらに9時間を足す必要はありません。
タイムゾーンが付いていない 2026-09-18 09:30 だけの文字列では、UTCか日本時間かを判断できません。サービスの表示設定やデータの仕様を確認してください。利用者に合わせて自動変換する画面では、元データがUTCでも表示はすでに日本時間になっている場合があります。
海外の現地時刻はUTCと同じとは限らない
「海外の9時」を一律に9時間足して変換することはできません。UTCとJSTの関係は固定ですが、海外の現地時刻には地域ごとの時差があり、夏時間のある地域では対象日によって変わります。
たとえば案内に UTC-08:00 と明記されていれば、日本時間との差は17時間です。UTC-07:00 なら16時間になります。これはオフセットから求めた計算例であり、特定都市が一年中その時差であるという意味ではありません。
国名や略称だけで決めず、会議の開催日と都市名を確認するのが安全です。変換ツールでも対象の日付を入れ、夏時間の切り替え付近では主催者のカレンダー招待と突き合わせてください。
レポートや予約時刻がずれるときの確認順
サービスごとに日付の区切りが違うと、同じ出来事が別の日に集計されます。UTCの9月18日16時に起きた操作は、日本時間では9月19日1時です。件数の違いを見る前に、集計期間が同じ瞬間を指しているかを確認します。
Google Analyticsなどで使うタイムゾーンは、サービスの設定で確認します。GA4のセットアップ説明では、レポート用タイムゾーンを変更しても過去データは遡って変更されないことが説明されています。数字を合わせるためだけに設定を変更せず、変更前後の集計への影響を先に確認した方が良いです。
まず元の表示に付いた Z やオフセットを確認し、次に日付を含めて変換します。そのうえで相手側の表示設定と照合すれば、計算違いなのか、すでに変換済みなのかを切り分けられます。