カレンダーの招待が違う時刻で表示される理由

カレンダーのタイムゾーンに関する問題には、よく似たパターンがあります。自分には 09:00 の会議として表示されるのに、招待した相手には 15:00 と表示される。これは正常な現地時刻の違いかもしれませんが、双方に異なる開始時点が伝わっている場合もあります。数週間は正しかった予定が、時計の切り替え後に一時間ずれることもあります。就寝中にリマインダーが届く場合も同様です。

原因は表示処理とは限りません。予定を単に「9 時」として保存し、どのタイムゾーンの 9 時なのかを記録しなかったために、後続の処理がそれぞれ不足する情報を補っていることがあります。前提が違えば、結果も違ってしまいます。

ここでは、カレンダーでのタイムゾーンの扱い、問題が数週間後に現れる理由、予定の時刻と一緒にタイムゾーンを保存することで変わる点を説明します。

タイムゾーンのない時刻の問題

カレンダーが開始時刻を 2026-09-14 09:00 とだけ保存しているとします。複数人が参加する会議では、この情報だけでは不十分です。処理する側によって解釈が分かれる可能性があります。

ブラウザーのフォームは入力された時刻を送ります。CalDAV クライアントはタイムゾーン識別子も送りますが、サーバーが無視すれば現地の時計の値だけが残ります。エクスポート時には、形式上明確な時刻表現が必要なため、その値に誤って UTC の印を付けるかもしれません。一方、リマインダーの処理は保存値を現在の UTC 時刻と比較します。

四つの処理が、同じ値を四通りに解釈します。全員が UTC を使っていると、問題が見えないことがあります。ベルリンの参加者が加わるだけで、一部の予定の扱いが変わり、しかもエラーは表示されません。

同じタイムゾーンだけでテストしていると、この不具合を見落としがちです。異なる地域のユーザーを想定したテストなら、早めに発見できます。そうしないと、旅行や時計の切り替え、別のタイムゾーンの人への招待をきっかけに表面化します。

カレンダーの時刻を表す三つの方法

フローティング時刻は、その動作を意図しているなら有効です。ただし、たとえば 14 日の誕生日は、通常はタイムゾーンのない時刻ではなく日付として表します。共通の会議に使うと、各地で同じ時計の値が異なる実際の時点を指してしまいます。

終日予定は日付として保存し、タイムゾーン間の換算は行いません。祝日を UTC の時点に変換してから現地時刻に戻すと、グリニッジより西では前日の夕方にずれる可能性があります。日付を会議の開始時刻と同じように扱ってはいけません。

時計の切り替えで問題が現れる理由

UTC との差が常に一定なら、タイムゾーンの扱いはもっと簡単でしょう。しかし、多くの地域では差が変わります。切り替えによって、それまで気付かなかった不具合が見えるようになります。

ベルリンは冬に UTC+1、夏に UTC+2 を使います。繰り返しの会議を固定の UTC 時刻で計算すると、切り替え後は現地の時計で一時間ずれます。時点としては明確でも、朝 9 時の定例会ではなくなります。Europe/Berlin の予定を朝 9 時に保つには、繰り返しもそのタイムゾーンで計算する必要があります。タイムゾーン名を保存するだけでは足りません。

国をまたぐと、さらに複雑になります。ヨーロッパと北米では時計の切り替え日が異なるため、その間はロンドンとニューヨークの通常の時差が一時間変わります。この期間の長さは季節や年によって異なり、一定ではありません。カレンダーが正しく動いていても、片方の参加者の現地時刻が一時的に変わることがあります。

別の既定タイムゾーンを選んでも、この違いはなくなりません。「同じ時点」と「同じ現地時刻」は別の要件です。繰り返し予定に求める動作を決め、繰り返しの計算やクライアントとの交換でも維持されるか確認する必要があります。

UTC とタイムゾーンを一緒に保存する

具体的な時刻を持つ予定では、正確な UTC の時点と、現地時刻の入力に使ったタイムゾーンの両方を保存すると役立ちます。繰り返し予定では、その計算方法も重要です。

UTC を使えば、時点の比較、予定の並べ替え、重複の検出を曖昧さなく行えます。タイムゾーンは、元の現地時刻の意図を説明します。ただし、このフィールドを保存しても、すべてのエクスポートが繰り返し予定の情報を完全に保つとは限りません。出力形式とクライアントの処理を個別に確認してください。

実際の動作は次のとおりです。

• Web メールで予定を作成すると、入力した時刻とブラウザーのタイムゾーンが送られます。サーバーは UTC に変換し、タイムゾーンを保存します。ブラウザーがベルリンに設定されていれば、ベルリンが記録されます。
• 別の場所で予定を見ると、UTC がブラウザーの現地時刻に換算されます。例の日付ではベルリンが 09:00、サンフランシスコが 00:00 となり、同じ時点を指します。別の時期には時差が変わる場合があります。
• リマインダーは、明確な時点を使って比較できます。タイムゾーンによるこの曖昧さはなくなりますが、通知の配信はタスクスケジューラーや通知経路の稼働状況にも依存します。
• 編集時は、現在のブラウザーのタイムゾーンで時刻を表示します。必ずしも予定の元のタイムゾーンではありません。特に旅行後は、保存前に時刻と端末の設定を確認してください。

古い予定はどうなるか

古い予定には、タイムゾーンが保存されていない場合があります。自動的な再解釈は行わず、Web 画面は従来の表示方法を保ちます。既存の予定が突然移動するのを避けるためです。

これは意図的な方針です。後からタイムゾーンを割り当てるには推測が必要で、誤った推測は相談なしに予定を変えてしまいます。二年間 14:00 と表示されてきた予定を、自動修正で別の時刻にすべきではありません。手動で確認するときは、その 14:00 が元々何を意味していたかを先に調べてください。

古い予定は編集時にタイムゾーンを追加できます。Web メールでは、時刻付きの予定を保存するとブラウザーのタイムゾーンを送るため、先に現地時刻と端末設定を確認してください。API で説明だけを変更し、タイムゾーンのパラメーターを送らなければ、情報は補われません。変更しない予定は以前の動作を保ちます。

古い定例会が海外の参加者に誤った時刻で表示されるなら、元の時刻とタイムゾーンを確認して修正を保存します。その後、時計の切り替え前後の繰り返しも確認してください。保存し直すだけで、予定全体の計算が正しくなるとは限りません。

CalDAV、ICS と他のカレンダー

カレンダーは Web 画面だけで使えるものでは不十分です。Apple Calendar、Thunderbird、対応するモバイルアプリは CalDAV で接続できます。ただし、端末に Google カレンダーがあるからといって、任意の CalDAV サーバーに接続できるとは限りません。連携方法と互換性を別途確認する必要があります。

CalDAV で予定を受け取ると、サーバーはタイムゾーン識別子から対応する UTC の時点を保存します。受信した元のカレンダー文書を変更せず返す場合もあります。一方、Web メールで作った予定には UTC 値を生成します。すべての応答が同じ表現になるわけではありません。終日予定は日付として交換します。繰り返し予定では、交換後も現地の時刻が保たれるか確認してください。

互換性のあるクライアントなら、同じ時点を表示できます。たとえばベルリンの iPhone で作成し、リスボンのノートパソコンから Web メールで編集し、ニューヨークの Thunderbird で開いた予定です。それぞれの現地時刻は異なります。クライアントと端末の設定が正しいことが前提で、タイムゾーン名は IANA タイムゾーンデータベースに基づきます。

設定方法は各ガイドをご覧ください。macOS の Apple Calendar、iPhone と iPad、DAVx⁵ を使う Android、Thunderbirdに対応しています。Outlook の CalDAV 接続には通常サードパーティ製アドインが必要です。バージョンごとの制約は Outlook の接続ガイドで確認してください。

タイムゾーンの問題を避ける確認事項

国際会議のタイトルにタイムゾーンを記載する。「週次ミーティング（09:00 CET）」は、メールソフトが招待を誤って表示したときの参考になります。ただし CET は冬の標準時で、夏のベルリンは CEST です。年間を通して CET と書くのではなく、予定の日付に合う略称か、参加者が分かる都市名を使ってください。

予定の基準となるタイムゾーンに繰り返しを合わせる。ベルリンのオフィスの時計に合わせる会議なら、そのタイムゾーンを使い、繰り返しもそこで計算されるか確認します。海外の参加者は、切り替え期間に現地時刻が変わることがあります。会議の変更ではなく、地域間の時差が変わっただけかもしれません。

時計の切り替え時期には重要な会議を再確認する。ヨーロッパと北米は異なる日に切り替えるため、通常の時差が一時的に変わります。具体的な日付を調べ、双方の現地時刻を文面で確認してください。

日付だけが重要なら終日予定を使う。会議やカンファレンスの開催日を示すには適した形式です。ただし、参加者が決まった時刻に到着する必要があるなら、日付だけではなく時刻とタイムゾーンを指定した予定を作ります。時刻が不要な予定に、適当な開始時刻を付けないでください。

よくある質問

別のタイムゾーンの人には、なぜ違う会議時刻が表示されますか？

異なる現地時刻で同じ時点を示すのは正常です。問題なのは、参加者が実際に異なる開始時点を受け取った場合です。予定のタイムゾーンとクライアント設定を確認してください。タイムゾーンがなかったなら、元の時刻を確かめて正しいタイムゾーンを保存し、参加者と結果を確認します。

繰り返しの会議が一時間ずれたのはなぜですか？

夏時間と標準時の切り替えが原因かもしれません。固定 UTC 時刻の予定はその時刻を保ちますが、現地の時計では変わります。現地タイムゾーンで計算する予定は現地時刻を保ち、別の地域ではずれることがあります。望む動作は取り決め次第なので、繰り返しの計算とエクスポートを確認してください。

Web メールで予定を作ると、どのタイムゾーンを使いますか？

Web メールはブラウザーのタイムゾーンを取得し、時刻付きの予定で送信します。サーバーは UTC の時点とタイムゾーンを保存します。特に現在地とは別のタイムゾーンに合わせる予定では、作成前に端末設定を確認してください。

終日予定も時刻を換算しますか？

いいえ。終日予定は時点ではなく日付として保存します。UTC を経由して換算すると、別のタイムゾーンの人には前日や翌日に見えることがあります。

タイムゾーンを保存する前に作成した予定はどうなりますか？

タイムゾーンを自動的に割り当てず、従来の動作を保ちます。Web メールで時刻付きの予定を保存するとブラウザーのタイムゾーンを追加するので、先に時刻と端末設定を確認してください。API 更新でタイムゾーンを明示しなければ、古い記録には追加されません。

Apple Calendar と Google カレンダーでも正しく扱えますか？

対応する CalDAV クライアントが正しく設定されていれば、予定の時刻を換算できます。Apple Calendar には接続ガイドがあります。Google カレンダーは利用できる連携方法を確認してください。任意の外部 CalDAV サーバーに接続できるとは保証できません。繰り返しと夏時間への切り替えも確認が必要です。

API でタイムゾーンを明示できますか？

はい。予定の作成と更新を行う REST API はタイムゾーンのパラメーターを受け付けます。MCP ではツールのスキーマを確認し、対応している場合にそのフィールドを送ります。省略しても、システムが意図したタイムゾーンを常に推測できるわけではありません。

古い予定のリマインダーが違う時刻に届くのはなぜですか？

タイムゾーンなしで保存した時刻を現在の時点と比較すると、結果がずれることがあります。元の時刻を確かめ、適切なタイムゾーンを保存してリマインダーを試してください。解消しない場合は、通知設定とタスクスケジューラーの動作も確認します。