記事
タイムゾーンをまたいだ会議のスケジュール
3つの都市の人が全員参加できる会議時間を選ぶのは、時計が変わって全員が1時間遅れるまでは簡単に見えます。このガイドではUTCオフセットの仕組みを順を追って説明し、夏時間がスケジュールエラーの主な原因である理由を解説し、すべての参加者の業務時間内に収まるウィンドウを繰り返し見つけるための方法を示します。
UTCとオフセット：基礎
協定世界時（UTC）はすべての標準時の共通基準点です。すべてのタイムゾーンはUTCに時間と分を加減したものとして表されます。冬のニューヨークはUTC-5、冬のパリはUTC+1、東京はUTC+9です。UTCで時刻を書けば、どこにいる人でも推測なしに現地時刻に変換できます。 ほとんどのオフセットは整数時間ですが、すべてではありません。インドはUTC+5:30で半時間が加わり、驚かれることがあります。ネパールはUTC+5:45でさらに進み、歴史的・政治的な理由で45分オフセットが存在します。オーストラリアの一部ではUTC+9:30とUTC+10:30が使われています。タイムゾーンが整数時間オフセットとして表示されている場合でも確認が必要です。同じ地域に時間未満のタイムゾーンが存在する可能性があります。 実用的なルールは、すべてのカレンダー招待をUTCで設定することです。多くの国で現地時刻は年に2回変わりますが、UTCは変わりません。
夏時間：オフセットがずれる理由
夏時間（DST）は春に時計を1時間進め、秋に戻すことで、その国のUTCオフセットを数か月間1時間ずらします。米国は3月の第2日曜日と11月の第1日曜日に時計を変えます。欧州の大半は3月の最終日曜日と10月の最終日曜日に変えます。南半球のオーストラリアは10月と4月に変えます。日本・インド・中国・アフリカのほとんど・東南アジアを含む多くの国はDSTを観測しません。 その結果、3月と10月の2〜3週間は2つの都市の差が覚えている数値とは異なります。ニューヨークからロンドンは通常5時間の差ですが、3月のその2〜3週間は4時間の差になります。米国はすでに時計を変えているのに英国はまだ変えていないからです。これが国際カレンダーでスケジュールエラーが最も多く発生する原因です。 唯一安全な戦略は、会議の特定の日付のオフセットを確認することです。先月覚えたオフセットではなく。
重複ウィンドウを見つける
会議当日の各参加者の所在地のUTCオフセットを書き出します。次に各都市の行を作成し、その都市の09:00〜18:00に対応するUTC時間をマークします。すべての行の交差点が候補スロットです。 具体的な例として、ニューヨーク（冬はUTC-5）・ロンドン（UTC+0）・ムンバイ（UTC+5:30）。ロンドン09:00はUTC 09:00、ニューヨーク09:00はUTC 14:00、ムンバイ18:00はUTC 12:30です。3都市すべてが業務時間内になる重複はほぼありません。ロンドンとニューヨークはウィンドウを共有しています（UTC 14:00〜17:00、ロンドン14:00〜17:00・ニューヨーク09:00〜12:00）が、ムンバイはUTC 12:30にすでに18:00を過ぎています。誰かが標準業務時間外のスロットを受け入れる必要があります。 この種の計算がまさにこのサイトのタイムゾーン差分ツールが処理するものです。2つの都市と日付を入力するとオフセットが表示され、その日付がDST移行ウィンドウ内かどうかも示されます。
定期会議の実践的な習慣
すべての招待にタイムゾーンを明記してください。「15:00」と書くだけでは曖昧です。「15:00 UTC」や「15:00 CET (UTC+1)」と書くことで推測を排除できます。カレンダーアプリは各受信者の現地時刻に変換しますが、ゾーンが明示されている場合のみです。 1回限りの会議の場合、招待を送る前にタイムゾーン変換ツールで特定の日付のUTCオフセットを確認してください。毎週繰り返す会議の場合、各DST移行日に何が起こるかを確認してください。「ニューヨーク時間10:00」に固定された会議は年に2回ロンドンの参加者に対して1時間ずれます。そのずれを受け入れ事前に参加者に通知するか、会議をUTCで固定して各自のカレンダーが現地時刻に変換するようにするかのどちらかです。 分散チームで広く使われているシンプルな慣習：すべてをUTCでスケジュールし、招待本文に最も参加者が多い2〜3のタイムゾーンの現地時刻を記載し、各DST移行日の2週間前に現地時刻が変わることを参加者に知らせるカレンダーメモを追加します。ワールドクロックツールでは現在のUTC時刻に対して複数の都市を一度に確認でき、送信前の簡易チェックに便利です。
ブラウザでローカルに行う
この記事を裏付ける3つのツールはブラウザ上で完全に動作します。時刻データ・都市名・スケジュールの詳細はデバイスを離れません。 タイムゾーン変換ツールは日付・時刻・ソースゾーンを受け取り、1つ以上のターゲットゾーンに変換します。指定した日付のDSTを考慮するため、表示されるオフセットはそのゾーンの標準オフセットではなく当日の実際のオフセットです。 ワールドクロックツールは複数の都市の現在時刻を並べて表示します。「シンガポールは今何時？」という問いにSearch Engineを開かずに答えるのに最も速い方法です。 タイムゾーン差分ツールは指定した日付の2つのゾーン間の時間差を計算します。日付を認識するため、2つのゾーンがまだ両方とも移行していない移行週を正しく処理します。 3つのツールはすべてページが読み込まれると、オフラインでも動作します。計算にはブラウザにバンドルされたIANAタイムゾーンデータベースを使用するため、DSTルールはブラウザのバージョンと同等に最新です。
この記事で紹介するツール
よくある質問
どちらの都市もタイムゾーンを変えていないのに、3月に2都市間のオフセットが変わるのはなぜですか？
異なる日付に時計を変えたからです。1つの国がDST移行を適用し、もう1つの国がまだ行っていない場合、その間の日数は両者の差が1時間縮まるか増えます。両方の国が移行を完了するとこれは解消されます。
インドはUTC+5:30です。夏時間を観測していますか？
いいえ。インドは1945年以来DSTを観測していません。UTC+5:30のオフセットは年間を通じて一定です。UTC+5:45のネパールもDSTを観測しません。そのため南アジアの参加者とのスケジューリングは欧州や北米の参加者とのものより予測しやすいです。
会議の招待はUTCで送るのと主催者の現地時刻で送るのはどちらがよいですか？
国際会議にはUTCの方が安全です。ほとんどのカレンダーアプリはソースゾーンが明示されていれば受信者の現地時刻で表示します。UTCはずれません。東部時間のようなDSTを観測するゾーンで招待を送ると、異なる日付に移行するゾーンの受信者には移行前後の数週間に誤った現地時刻が表示されることがあります。