複数の都市・タイムゾーンの現在時刻を同時に確認し、ある時刻を別のタイムゾーンに変換できます。海外との打ち合わせのスケジュール調整に便利です。
理屈のうえでは経度15度ごとに1時間ですが、実際の境界線は国境や行政の都合で引かれています。地図の縦線どおりにはなっていません。
中国は理論上5つのタイムゾーンにまたがる国土を、全土ひとつ(UTC+8)で運用しています。西端の新疆では、夏の日没が夜10時近くになります。
30分・45分刻みのオフセットも実在します — インド(UTC+5:30)、イラン(+3:30)、ネパール(+5:45)、オーストラリア中部(+9:30)。
そのため、経度から時差を暗算する方法はよく外れます。都市名で確かめるのが確実です。「アジアはだいたい何時間差」といった感覚は、インドやネパールで崩れます。
サマータイム(DST)を採用している地域は、年に二度オフセットが変わります。ニューヨークとロンドンの差はふだん5時間ですが、切り替え日が違うため一時的に4時間や6時間になります。
アメリカは3月の第2日曜と11月の第1日曜、EUは3月と10月の最終日曜に切り替えます。そのあいだの数週間は、ふだんと違う時差で動くことになります。
南半球は逆です。 オーストラリア、ニュージーランド、チリは、北半球が冬のあいだにサマータイムを実施します。
日本、中国、インド、韓国はサマータイムを採用していません。 日本では戦後の一時期に実施されたきりで、現在は制度そのものがありません。
このツールはブラウザ内蔵のIANAタイムゾーンデータベースを使うので、その日付に実際に適用される規則で計算します。3月や11月をまたぐ予定でも、日付ごとに正しい時差が出ます。
「10時」とだけ書かないでください。 必ずタイムゾーンを添えます — 「10:00 JST」と書けば、受け取った側が自分の時計で読み違えることはありません。
UTCで書くのがいちばん安全です。 サマータイムの影響を受けない唯一の基準だからです。「14:00 UTC」は世界のどこでも同じ瞬間を指します。
日付がまたぐことを見落とさないでください。 東京の朝9時はニューヨークでは前日の夕方です。「火曜の会議」が、相手にとっては月曜になることがあります。
アジアと北米で現実的に重なるのは、アジアの早朝と米国東部の夕方、あるいはアジアの夜遅くと米国東部の午前です。ゴールデンウィークやお盆に日程を置くと、日本側だけ不在という事故も起きます。
ヨーロッパとの打ち合わせなら、東京の夕方がロンドンやパリの午前にあたるため、双方の勤務時間に収まる枠を取りやすくなります。参加者が三大陸にまたがるときは、誰かが必ず早朝か深夜を負担することになるので、その負担を回ごとに交代させる決め方が現実的です。
太平洋上の日付変更線を西へ越えると日付が1日進み、東へ越えると1日戻ります。成田からホノルルへ飛ぶと、出発した日と同じ日付の、しかも出発より前の時刻に着くことがあります。
この線はまっすぐではなく、島国や領土を避けて折れ曲がっています。キリバスは1995年に線を東へ動かし、国全体を同じ日付にそろえました。
その結果、極端な差が生まれます — キリバス(UTC+14)とハウランド島(UTC−12)は26時間差で、地球上に二つの日付が同時に存在していることになります。
サモアは2011年に12月30日をまるごと飛ばしました。貿易相手であるオーストラリアやニュージーランドと日付を合わせるためです。
UTCは原子時計に基づく国際標準です。GMTは歴史的なグリニッジ標準時で、日常の用途ではほぼ同じものとして扱われます。
略称は信用しないでください。 CSTはアメリカ中部時間(UTC−6)、中国標準時(UTC+8)、キューバ標準時(UTC−5)のどれにもなり得ます。
ISTもインド(+5:30)、アイルランド、イスラエルが同じ略称を使っています。メールに「IST」とだけ書かれていたら、国を確認しないと決められません。
だから技術文書やカレンダーでは、UTCオフセットかIANAの識別子(Asia/Tokyo)を書くのが標準になっています。
ブラウザのIntl.DateTimeFormatとIANAタイムゾーンデータを使って計算しています。外部APIを呼ばないため、オフラインでも動作します。
タイムゾーンの規則は政府の決定で変わり、世界のどこかで毎年何件か起きています。ブラウザを更新すればデータも新しくなりますが、非常に古いブラウザは最近の変更を知らないことがあります。
重要な予定では、都市名とオフセットの両方を書き添えておくと、あとで規則が変わっても何時のことだったかを取り違えずに済みます。
「サマータイム中は1時間ずれる」だけでは足りません。 ずれているのが相手側なのか自分側なのか、あるいは両方なのかで結果が変わります。二つの都市を並べて同じ瞬間として見るのが確実です。
航空券に書かれた出発・到着時刻は、どちらもその土地の現地時間です。 引き算しただけの数字が飛行時間と合わないのは、そこに時差が混ざっているためです。所要時間は別に確認してください。
カレンダーアプリに登録するときは、開催地のタイムゾーンを指定してください。 自分の端末の時計だけで入力した予定は、出張先に着いた瞬間に表示時刻が動いてしまいます。
定例会議は切り替え日をまたぐと相手側の時刻だけがずれます。 3月と11月の前後は、いつもどおりの招待を送る前に一度並べて確認しておくと安全です。
深夜や早朝の時刻は日付とセットで伝えてください。 「0時」や「24時」は受け取り手によって前日と当日のどちらにも読まれます。日付を添えれば曖昧さは消えます。
はい。各地域の現在の規則に沿って自動で反映します。
はい。ある都市の時刻を入れると、他の都市の現地時刻が同時に出るので、全員の日中に収まるか確認できます。
上限はありません。よく使う都市を並べて置いておけます。
このツールが何を根拠に計算し、どこまで答えられるかを明示します。
各都市に IANA のタイムゾーン識別子(Asia/Seoul, America/New_York)を割り当てています。一つの絶対時刻を Intl.DateTimeFormat で各タイムゾーンに整形するため、夏時間や過去のオフセット変更は固定オフセットの計算ではなく実行環境のデータから来ます。12:00 UTC は Asia/Seoul では 21:00 です(年間を通じて UTC+09:00)。同じ瞬間は America/New_York では米国の夏時間中は 08:00(UTC−04:00)、それ以外の期間は 07:00(UTC−05:00)です。