タイムゾーン計算

変換先の壁時計 = 変換元の壁時計 − 変換元のUTCとの時差 + 変換先のUTCとの時差。変換元との差 = 変換先の時差 − 変換元の時差。日付のずれ = 変換先の日付 − 変換元の日付

日付

変換元での暦の日。YYYY-MM-DDの形で書きます。あなたが読んでいる場所の日ではなく、向こう側の日です

時刻

変換元での時刻。24時間制のHH:MMまたはHH:MM:SSで書きます。秒は省けますが、結果には必ず表示されます

変換元のタイムゾーン

入力した時刻が属するゾーン。22のIANAゾーンのうちの1つで、それぞれが時差ではなく都市名で示されます。時差は場所の性質ではなく、その瞬間の性質だからです

変換先のタイムゾーン

変換先のゾーン。変換元と同じ22のゾーンです

変換先の時刻

変換先のゾーンでの時刻。秒まで必ず付きます。これが見出しの結果です

変換先の日付

変換先のゾーンでの暦の日。入力した日付と同じとは限りません。日付のずれがこのページの要点です

変換先の曜日

変換先のゾーンでの曜日。0（日曜）から6（土曜）までの数で示します

変換元のUTCとの時差

変換元のゾーンが、実際に解決された瞬間においてUTCからどれだけ離れているか。UTC±HH:MMの形です

変換先のUTCとの時差

同じ瞬間における変換先のゾーンの時差。どちらも変換後の瞬間で読むので、その土地で夏時間が効いていれば両方に含まれます

変換元との差

変換先の時差から変換元の時差を引いたもの、時間単位。マイナスなら変換先のほうが遅れています

日付のずれ

−1、0、+1。変換先の日付が、入力した日の前日か、同じ日か、翌日かです

2つの場所が関わり、時計を信用しなければならない場面で使います。海をまたいだ通話の予約、離陸した日と同じ日に着くかどうかの確認、UTCで書かれたサーバーログの解読、友人の「日曜の朝」がこちらの日曜の夕方になる理由の確認などです。手計算でいちばん間違えやすいのが日付のずれで、これは2つの都市の組に固定された性質ではありません。同じ2つのゾーンでも1月は12時間、7月は11時間違います。このページが変換するのは、すでに手元にある1つの瞬間です。ある場所がどのゾーンにあるかを教えるものではなく（一覧は22ゾーンで固定です）、移動時間、フライトの所要時間、予定のリマインダーについても何も言いません。

1. 上海の正午からニューヨークへ 前日になる場合

   1. 上海は1月にはUTC+08:00なので、そこの正午は1月15日の04:00 UTC
   2. ニューヨークはESTでUTC−05:00なので、04:00 UTCはそちらの時計で23:00
   3. 23:00は真夜中より手前なので、日付は1月14日になる。入力した日の1日前で、日付のずれは −1としてそう答えている
   4. 2026年1月14日は水曜なので、曜日の数は3
   5. 2つの時差の差は −13時間。08:00 − (−05:00) は13時間で、変換先のほうが西にある

   この電卓の初期状態であり、いちばん人を驚かせる場合です。上海で昼どきに送ったメッセージは、ニューヨークには前の暦の日に届きます。「上海は12時間か13時間進んでいる」という1つの規則で手計算するときが、間違いが忍び込む場所です。ここでの答えは13時間ですが、7月なら12時間になります。ニューヨークが夏時間で、上海はそうではないからです。

2. 存在しない時刻 ニューヨーク、2026年3月8日02:30

   1. ニューヨークの時計はこの日の現地時刻02:00に進むので、02:00が03:00になり、02:00から03:00までの30分は存在しない
   2. したがって入力した02:30は存在しない。ページは空白に対してIANAの規則が定めるとおりに読み、前へずらして03:30 EDTとする
   3. 2026年3月8日の03:30は日曜なので、曜日の数は0
   4. 解決された瞬間はすでにEDTにあるので、表示される変換元の時差はUTC−04:00になる。前日に02:30が持っていたUTC−05:00ではない
   5. 上海はUTC+08:00で、EDTより12時間進んでいるので、03:30は同じ日の15:30になる

   入力した時刻の横に出る時差は、理由が分かるまでは間違って見えます。ニューヨークの02:30は冬ならUTC−05:00の壁時計ですが、この特定の02:30は切り替えのあとの空白に入っているので、解決される瞬間はEDTのものになり、UTC−04:00を報告します。ページは空白と重なりをIANAのタイムゾーンデータベースが定めるとおりに読み、入力を拒否することはありません。だから数はいつも出てきます。この例は2度読む価値のある場合です。

3. 両端とも夏時間7月4日のロンドンからロサンゼルス

   1. 7月のロンドンはBSTでUTC+01:00なので、そこの09:30は08:30 UTC
   2. ロサンゼルスはPDTでUTC−07:00なので、08:30 UTCはそちらの時計で01:30
   3. 時差の差は8時間で、冬に人が期待する8時間でもあります。ただしその2つの8時間は別物です。1月のロンドンはUTC+00:00で、ロサンゼルスはUTC−08:00
   4. 表示される時差はどちらも夏時間を含んでおり、変換元がUTC+00:00ではなくUTC+01:00と出るのはそのためです
   5. 日付は変わらないので日付のずれは0で、2026年7月4日は土曜、曜日の数は6

   標準の時差（0と −08:00）で答えると同じ8時間差、同じ壁時計の時刻になります。だからこの間違いはここでは見つけにくく、切り替えの前後の日付で表面化します。3月の同じ週に両方のゾーンが逆方向へ動くときが、固定した時差の規則がまる1時間ずれる瞬間です。

4. オークランドの元日は、UTCではまだ前の年

   1. 1月のオークランドはNZDTでUTC+13:00なので、そこの真夜中は2025年12月31日の11:00 UTC
   2. したがってUTCへの変換は、日の境目と年の境目を同時に越えます
   3. 変換先の日付は2025年12月31日で、日付のずれ −1は日付の文字列を比べるのではなく日数の差を取って求めている
   4. 2025年12月31日は水曜なので、曜日の数は3
   5. 時差の差は −13時間。変換先のUTCのほうが西にある

   日付のずれは単純な「西は昨日」ではありません。ここでは −13時間が真夜中を越えていますが、上海とニューヨークのあいだの同じ −13時間も前日になりますし、ロンドンからニューヨークへの −5時間はそうなりません。曜日は変換先の日付について報告されるので、入力した日が木曜なのに水曜と出ます。

この電卓が扱うのは1970年から2100年までと22のタイムゾーンで、IANAデータベースが知っているすべてのゾーンではありません。範囲をこう定めているのは意図的です。1970年より前、データベースが記録しているのはその土地が実際に使っていた地方平均時で、上海はUTC+08:06でしたし、モンロビアは秒を含む時差を使っていました。そうした答えは正しいのですが、不具合に見えてしまいます。曖昧な時刻と存在しない時刻は、拒否するのではなくIANAの規則どおりに解決します（春の切り替えの空白では前へずらし、秋の重なりでは早いほうの読みを取ります）。ページはそのことを警告しないので、切り替えの前後の日付は表示された時差と突き合わせて確かめる価値があります。入力した地名からゾーンを推測することはありません。そもそも入力する場所がなく、どちらの一覧も固定です。このページはあなたの端末がどのゾーンにあるかを知りませんし、所要時間やフライトの時間も扱いません。うるう秒も入れていません。ここでの計算は1日を86,400秒として数えており、UTCそのものに加えられるうるう秒は勘定に入っていません。

2つの都市の時差はどれだけか

都市間の時差は固定の数ではなく、このページが出す変換元との差は入力した日付に効いているものです。一方が夏時間を採用していてもう一方が採用していなければ、同じ2つのゾーンが1月は13時間、7月は12時間違うことがあります。ですから「上海とニューヨークの時差は」という問いは、日付を添えて初めて成立します。ここで日付の欄が省略できるおまけではなく問いの一部になっているのは、そのためです。

会議の時刻はどう調整するのか

まず提案されたゾーンにそのまま置き、それを順にほかのゾーンへ変換します。会議の時刻をまたいで見るときに役に立つ数は、多くの場合、時間そのものより日付のずれです。ロンドンの09:00は東京では同じ日の18:00ですが、ニューヨークでは04:00で、招待を出すのが筋かどうかを決めるのはこの04:00のほうです。曜日と日付も出るので、提案が相手側の週末に着地していないかも分かります。

夏時間は自動で適用されるのか

はい、両方のゾーンについて、しかも今日ではなく入力したその日付について適用されます。夏時間はゾーンの性質ではなく瞬間の性質です。出てくる時差は、変換しているその瞬間についてIANAの規則が与えるもので、同じ2つのゾーンでも1月の日付と7月の日付では1時間違うことがあります。現在の日付は一切前提にしていません。つまり来年3月について計算した結果には、来年3月の切り替えがすでに入っています。

UTCとの時差が思っていたのと違うのはなぜか

表示される時差は、入力した壁時計のものではなく、入力が解決された瞬間のものだからです。時計が進む日には、飛ばされた1時間は存在せず、その時刻に入力された値はその直後の瞬間として読まれます。ですから3月の切り替え日にニューヨークで02:30を入れると、前日に02:30が持っていたUTC−05:00ではなくUTC−04:00（EDT）と表示されます。どちらも同じ瞬間の読み方ですが、そのときに効いている時差は片方だけです。

こちらが水曜なら、そちらは何曜か

ゾーンだけでなく時刻にもよります。それがこのページが両方を尋ねる理由です。日付変更線を東へ越えれば1日増え、西へ十分な時間だけ越えれば1日減ります。日付のずれの欄が −1、0、+1で直接答え、曜日の欄が変換先の曜日を示すので、向こう側がもうあなたの尋ねている日になっているかどうかも分かります。

• IANA Time Zone Database — Internet Assigned Numbers Authority
• Theory and pragmatics of the tz code and data — IANA — このページが掲げる1970年1月1日以降という対象範囲の出典
• Temporal documentation — Time zone handling：時刻が曖昧になる場合と、存在しない場合の扱い — TC39 — 曖昧な時刻と存在しない時刻について、このページが従う「compatible」の解決規則を定めている