このツールでできること
基準にする都市を選び、その都市の壁時計で見た日付と時刻を入力して「変換」を押すと、同じ瞬間が一覧の11都市それぞれの現地時刻で表示されます。各行には現地の日付・曜日、UTCとの差(オフセット)、基準都市と日付がずれる場合の「前日/翌日」の表示、夏時間(サマータイム)が適用中であればその表示が付きます。海外との会議の調整、海外配信の開始時刻の確認、相手に電話してよい時間帯かどうかの判断などに向いています。時刻欄を空にすると、お使いの端末の現在時刻の数字を「基準都市の時刻」とみなして変換します。
注意したいのは、入力する値が「パソコンの時刻」ではなく基準都市の時刻だという点です。たとえば東京にいて「ニューヨークの午前9時」が各地で何時かを知りたいなら、基準都市をニューヨークにして09:00と入力します。
時差計算のしくみ
各地の時刻は、協定世界時(UTC)にオフセットを足したものです。2都市間の変換は常に次の3段階です。
- 基準都市の現地時刻からそのオフセットを引き、UTCを求めます(東京09:00、オフセット+9時間なら、UTCの00:00)。
- そのUTCに目的地のオフセットを足します(UTC 00:00にオフセット-5時間を足すと、前日の19:00)。
- 0時をまたいだら、日付も前後にずらします。
難しいのは、同じ都市でもオフセットが一年中同じとは限らないことです。このページは固定のオフセット表を持たず、標準のIntl.DateTimeFormat APIを使って、変換する瞬間にその都市の時計が何時何分を示すかをブラウザに尋ね、その差からオフセットを求めています。したがって結果は、お使いのブラウザが持つIANAタイムゾーンデータベースの、その日付における規則に従います。
IANAのゾーン名と略称の違い
メニューの各都市は、America/New_York、Europe/London、Asia/Kolkataのような「地域/都市」形式のIANAタイムゾーン識別子で管理されています。識別子は場所と、その場所の規則変更の履歴をまとめて指すものです。一方、CSTやISTのような略称は曖昧で、CSTは北米の中部標準時にも中国標準時にも使われ、ISTはインド・アイルランド・イスラエルなどで使われます。時刻を共有するときは、都市名や「その日付でのUTCとの差」を添えると誤解を防げます。また、1つの国が複数のゾーンを持つ場合があり、「ニューヨーク」はアメリカ東部のゾーンの代表であって国全体ではありません。
都市別のUTCオフセット(参考表)
次の表はページのビルド時に、ツールと同じ考え方でタイムゾーンデータベースから計算した値です。年の前半と後半から1日ずつ、2026年1月15日と7月15日を選び、各都市を東京と比べています。夏時間の規則は各国の政府が決めるもので変更されることもあるため、表は例として見て、重要な予定は公式の情報や最新のタイムゾーン情報で確認してください。
| 都市 | IANAゾーン | 1月15日 | 7月15日 | 東京との差(1月) | 東京との差(7月) | 夏時間で変動 |
|---|---|---|---|---|---|---|
| ソウル | Asia/Seoul | UTC+9 | UTC+9 | 0 | 0 | なし |
| 東京 | Asia/Tokyo | UTC+9 | UTC+9 | 0 | 0 | なし |
| 北京 | Asia/Shanghai | UTC+8 | UTC+8 | -1 | -1 | なし |
| バンコク | Asia/Bangkok | UTC+7 | UTC+7 | -2 | -2 | なし |
| ニューデリー | Asia/Kolkata | UTC+5:30 | UTC+5:30 | -3.5 | -3.5 | なし |
| ドバイ | Asia/Dubai | UTC+4 | UTC+4 | -5 | -5 | なし |
| ロンドン | Europe/London | UTC+0 | UTC+1 | -9 | -8 | あり |
| パリ | Europe/Paris | UTC+1 | UTC+2 | -8 | -7 | あり |
| ニューヨーク | America/New_York | UTC-5 | UTC-4 | -14 | -13 | あり |
| ロサンゼルス | America/Los_Angeles | UTC-8 | UTC-7 | -17 | -16 | あり |
| シドニー | Australia/Sydney | UTC+11 | UTC+10 | +2 | +1 | あり |
差の列は「その都市の時計 − 東京の時計」を時間単位で表したものです。たとえば-14なら、東京が正午のときその都市は前日の22:00という意味です。最後の列が「あり」の都市は、1月と7月でオフセットが異なる、つまり夏時間を採用している都市です。シドニーは南半球なので、北半球の冬に時計が進んでいます。ニューデリーの+5:30のように、1時間単位ではないオフセットもあります。
検算した計算例(同じIntl計算で確認)
例1. 東京の2026年1月15日(木)09:00はUTCの00:00です。このときロンドンは同じ木曜の00:00、シドニーは木曜の11:00、ニューヨークは1月14日(水)の19:00です。ニューヨークは日付が異なるため「前日」と表示されます。
例2. ロンドンの2026年7月15日(水)12:00は、7月のロンドンが夏時間(UTC+1)なのでUTCの11:00です。東京は20:00、ニューデリーは16:30、ニューヨークは07:00、ロサンゼルスは04:00で、いずれも同じ水曜日です。ニューヨーク側にとって07:00開始は早い時間帯なので、招待を送る前に気づけるのが利点です。
例3. ロサンゼルスの2026年1月15日(木)20:00は、金曜のUTC 04:00です。東京は金曜の13:00、ニューデリーは金曜の09:30になり、カリフォルニアの夜は日本ではすでに翌日の午後です。
よくある落とし穴と限界
- 切り替え時期のずれ。 時計を動かす日は地域ごとに違うため、年に数週間は2都市間の時差が普段と1時間ずれます。定例会議を片方の都市の同じ時刻に固定すると、他の参加者には1時間ずれて見えることがあります。切り替え日の前後は確認してください。
- 存在しない時刻と、2回ある時刻。 時計を進める日には1時間が飛び、戻す日には1時間が2回現れます。飛ばされる時刻を入力した場合は有効な時刻に補正し、注意書きを表示します。2回ある時刻は現地時刻だけでは瞬間が1つに決まらず、このページは1通りに解釈して警告は出しません。その時間帯の予定は避けるか、UTCで示してください。
- 都市と国は別物。 11都市はそれぞれのゾーンの代表例です。同じ国でも別の地域では異なるオフセットを使うことがあります。
- データはブラウザ由来。 ブラウザに同梱されたタイムゾーンデータを使います。更新はブラウザ本体の更新に合わせて行われるため、ごく古い日付や遠い将来の日付は、まだ取り込まれていない規則変更の影響を受けることがあります。
- 夏時間の判定方法。 「夏時間」表示は、その日のオフセットを同じ年の1月・7月のオフセットと比べて推定しています。過去に夏時間を変更・廃止した地域もあるので、特殊な例は別途確認してください。
- 法的な期限には使わない。 航空券、契約、届出の期限などは、公式の文言とそこで指定されたタイムゾーンを基準にしてください。
結果の使い方
- 複数拠点の会議では、一度変換して全員の現地時刻を見渡し、業務時間外になる人がいないか確認します。いる場合は基準時刻を1時間ずつ動かして再変換し、最も条件の悪い人が許容できる時間帯を探します。
- 「結果をコピー」で全行をチャットや招待に貼り付けると、日付・曜日・オフセットも含まれるので、相手が自分で計算する必要がなく、日付が違う都市には「前日/翌日」が付きます。
- 配信や締め切りのような単発の予定は、その日付まで入力して当日のオフセットで確認します。定例の予定は、各地域の切り替え時期の前後に見直してください。
よくある質問
夏時間(サマータイム)は反映されますか?
はい。入力した日付についてブラウザのタイムゾーンデータからオフセットを求めるため、夏時間を採用している都市は自動でずれ、適用中なら表示されます。注意が要るのは、切り替え当日の夜に飛ぶ・繰り返される時間帯だけです。
時刻を入力しないとどうなりますか?
端末の現在時刻の数字を、基準都市の壁時計の時刻とみなして変換します。端末の場所と基準都市が違う場合は、時刻を直接入力するか、基準都市を今いる場所に合わせてください。
同じ2都市でも季節によって時差が変わるのはなぜですか?
時計を動かす地域と動かさない地域があるためです。片方だけが1時間動くと時差が1時間増減し、地域ごとに切り替え日が違うので、しばらくの間ずれが続きます。
UTCとGMTは同じですか?
日常では同じ時刻を指します。厳密には、GMTはグリニッジ子午線での平均太陽時が起源で、UTCは原子時計を基に維持される現在の標準です。イギリスは冬にGMT、夏にUTC+1の英国夏時間を使います。
30分刻みのオフセットがあるのはなぜですか?
国によっては、標準時を1時間単位から30分や45分ずらして定めているためです。表のインドのUTC+5:30が一例です。このツールはデータベースの値をそのまま使うので、端数のあるオフセットも正しく計算されます。