ISO 8601 日本時間 変換ツール

2026-09-26T15:30:45Zは日本時間で9月27日午前0時30分45秒です

ISO 8601の時刻の末尾にあるZはUTC(協定世界時)を表し、日本標準時(JST)はUTCより9時間進んでいます。そのため、Z付きの時刻に9時間を足すと日本時間になり、UTCの15:00から24:00までの時刻は、日本ではすでに翌日です。反対に、末尾が+09:00の値は最初から日本時間なので、9時間を足してはいけません。

上の変換ツールの入力欄に日付・時刻の文字列を貼り付けると、形式を自動で判別し、日付・時刻・小数秒・時間帯のどこがどの部分かを色分けして示します。答えの下にある帯は、UTCの1日と日本の1日を同じ時間軸に重ねて描き、日付が変わる位置と、日本の1日がUTCのいつからいつまでにあたるかを示します。ログを複数行貼り付ければ、日時の書かれた箇所だけをまとめて日本時間に変えることもできます。

UTCの時刻を日本時間に直す必要が出る場面

サーバーやプログラムは、地域によって値が変わらないUTCや、オフセット付きのISO 8601で時刻をやり取りすることが多くあります。人がその値を読んで、日本で何時だったかを判断するときに、この変換が必要になります。

• APIやJSONのレスポンスを確認するとき: "createdAt": "2026-09-26T15:30:45.123Z"のようにZで終わる値はUTCです。問い合わせにある「昨夜0時30分の注文」と同じものかどうかを照合するには、日本時間に直す必要があります。
• サーバーログを読むとき: サーバーの時計をUTCに合わせていると、ログも[26/Sep/2026:15:30:45 +0000]のようにUTCで記録されます。障害の発生時刻を日本時間にしておくと、ほかの記録との前後関係を合わせられます。
• メールやHTTPのヘッダーを見るとき: Date: Sat, 26 Sep 2026 15:30:45 GMTのように曜日と英語の月名で書かれた値も、同じ瞬間を指します。
• データベースから日本の1日分を探すとき: UTCで保存された列から「9月27日の注文」を探すには、UTCの9月26日15時以上、9月27日15時未満で絞り込む必要があります。上の帯の下の行が、この範囲をSQL条件としてコピーできます。
• 設定値をUTCで渡すとき: 予約配信や有効期限をISO 8601のUTCで受け取るサービスに日本時間の予定を入れる場合や、AWSの署名のように20260926T153045Zという基本形式を作る場合です。

計算方法: 書かれたオフセットを引いてUTCに戻し、9時間を足します

日本時間 = 書かれた時刻 − 書かれたオフセット + 9時間

1. 末尾の時間帯表記を探します: Z(または+00:00)はUTC、+05:30はUTCより5時間30分進んだ地域、-04:00は4時間遅れた地域の時刻です。何も付いていなければ、文字だけではどの地域の時刻か分かりません。
2. オフセットを引いてUTCに戻します: 2026-09-26T08:00:00+05:30は、8時から5時間30分を引いてUTCの2時30分です。オフセットがマイナスなら、逆に足します。
3. UTCに9時間を足します: UTCの2時30分は、日本の11時30分です。1950年の夏時間のように、日本のオフセットが+9ではなかった時期は、そのときの値を使います(日本標準時の移り変わり)。
4. 24時を超えたら日付を1日進めます: UTC 15時30分 + 9時間 = 24時30分なので、翌日の0時30分です。逆に日本時間から9時間を引いて0時を下回れば、前日になります。

小数秒は、時間帯を変えても変わりません。オフセットは時・分の単位なので、秒より下の桁は動かないためです。この変換ツールも、.123や.123456789のように入力された桁をそのまま書き写します。

ISO 8601の文字列を部分ごとに読む

If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00".RFC 3339 4.3 Unknown Local Offset Convention。同じ文書の5.6は、TとZを小文字のt・zで書いてもよいと補足しています。

この変換ツールが読める形式

入力欄には、次の形式をそのまま貼り付けられます。前後の空白や全角の数字は自動で整えます。

数字だけを扱うことが多いなら、UNIXタイムスタンプ変換ツールのほうが、単位の判別や32ビットの範囲まで詳しく示します。

変換の例

UTCの15時から、日本は翌日です

日本時間はUTCより9時間進んでいるため、UTCの1日の終わりの9時間(15:00〜23:59)は、日本の日付では翌日になります。言い換えると、日本の1日は、UTCでは前日の15時から当日の15時前までです。

このため、データをUTCの日付でまとめて集計すると、日本の午前9時より前の記録が前日に入ってしまいます。日本の日付で集計するには、次のようにUTCの範囲を、終わりが開いた区間で指定します。

-- 日本時間 2026-09-27 の1日分
WHERE created_at >= '2026-09-26T15:00:00Z'
  AND created_at <  '2026-09-27T15:00:00Z'

終わりを23:59:59で閉じると、その後の小数秒(23:59:59.5など)が漏れるため、「翌日の0時未満」と書くほうが安全です。

コードで日本時間に変換する

プログラムの中では、9時間を自分で足すより、時間帯の名前(Asia/Tokyo)を渡すほうが、過去の夏時間まで正しく処理されます。

When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.ECMA-262 21.4.1.32 Date Time String Format。同じ文字列でも、時刻が付いているかどうかでJavaScriptが読む時間帯が変わります。

日本標準時が常に+09:00だったわけではありません

現在の日本標準時はUTC+09:00ですが、IANA時間帯データベース(Asia/Tokyo)には、標準時の始まりと、夏時間を実施した期間が記録されています。この変換ツールは、その記録に従い、そのときのオフセットで計算します。

IANAのデータでは、夏時間は1951年が最後で、それ以降のオフセットの変化はありません。そのため、1948-05-02 00:30は東京に存在しない時刻、1948-09-12 00:30は2回ある時刻です。時間帯のない値をこのような時刻で入力すると、変換ツールはどちらの側で読んだかを別に表示します。1888年より前のようにオフセットに秒が付く時期は、RFC 3339・RFC 2822の表記が時差を分までしか書けないため、その2行を空欄にします。

よくある間違い

• +09:00の値にさらに9時間を足す: 2026-09-27T00:30:45+09:00は、すでに日本時間です。9時間を足すと、まったく別の午前9時30分になります。
• 時間帯のない値をUTCとみなす: 2026-09-27 00:30:45には時間帯の情報がありません。保存したプログラムが日本時間で書いたのかUTCで書いたのかを確かめてから、上の「時間帯がない値は」の設定を選んでください。
• 日付だけを比べる: UTCの9月26日と日本の9月26日は、9時間ずれた別の1日です。日付ごとの集計は、どの時間帯を基準にするかを先に決める必要があります。
• Zと-00:00を区別しない: どちらもUTCの時刻ですが、-00:00には現地の時差が分からないという意味が加わります。メールヘッダーの-0000も同じ意味です(RFC 5322 3.3)。
• CSTやISTのような略語を信じる: CSTは米国中部標準時(-06:00)と中国標準時(+08:00)のどちらも指し、ISTはインド・アイルランド・イスラエルが使います。この変換ツールは、RFC 5322が値を定めた米国の略語だけをその値で読み、複数の国が使う略語は数字のオフセットで書き直すよう案内します。

制限

• 時間帯の計算は、使っているブラウザに入っているIANA時間帯データに従います。データの版によって、ごく古い時期や最近変わった地域のオフセットが異なる場合があります。
• 2026-W39-6のような週番号の日付、2026-269のような通算日の日付、09/26/2026のように月と日の順序が国ごとに異なる表記は読みません。
• 23:59:60のようなうるう秒はUNIX時間に存在しないため、次の秒の0秒として計算します。
• asctime形式(Sat Sep 26 15:30:45 2026)は、HTTPの規格ではUTCとみなされますが、プログラムによっては現地時刻で出力することもあるため、「時間帯がない値は」の設定に従います。
• 小数秒はナノ秒(9桁)まで受け付けます。時間帯の略語は、UTC・GMT・KST・JST・WIB・WITA・WIT・CET・CESTと、RFC 5322の米国の略語だけを読みます。

出典

• 01IETF RFC 3339: Date and Time on the Internet: Timestamps4.3 -00:00(現地の時差が不明)、5.6 date-timeの文法・小文字のt・zと空白区切りの許容、5.7 うるう秒60
• 02IETF RFC 5322: Internet Message Format3.3 date-time(曜日は日付と一致すること、-0000の意味)、4.3 旧時間帯略語UT・GMT・EST〜PDTの値
• 03IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsHTTP日付IMF-fixdateの例 "Sun, 06 Nov 1994 08:49:37 GMT"、asctime形式はUTCとみなす
• 04ECMA-262: 21.4.1.32 Date Time String Formatオフセットのない日付のみはUTC、日付と時刻は現地時刻として読む。21.4.4.41 Date.prototype.toStringの形式
• 05Pythonドキュメント: datetime.fromisoformat3.11からほとんどのISO 8601形式を読める。例 '2011-11-04T00:05:23Z' はUTC
• 06AWS: Signature Version 4 の日付の扱い"The time stamp must be in UTC and use the following ISO 8601 format: YYYYMMDDTHHMMSSZ"
• 07nginx: ngx_http_log_module$time_local "local time in the Common Log Format"
• 08PostgreSQLドキュメント: 8.5.2 Date/Time OutputISOスタイルの出力例 "1997-12-17 07:37:16-08"
• 09IANA Time Zone DatabaseasiaファイルのAsia/Tokyoの記録(1888年の標準時、1948〜1951年の夏時間)

出典の確認日は2026-10-20です。時間帯データは年に何度も改訂され、画面の時刻は使っているブラウザに入っている版に従います。

よくある質問

あわせて使うツール