タイトル、場所、日時、タイムゾーン、繰り返し、招待者、通知、メモを入力し、.ics ファイルをダウンロードするかカレンダーで直接開きます。日程を貼り付けたり、文書や写真を添付したりして、複数の予定をまとめて作成することもできます。
なぜカレンダーイベントが1時間、あるいは1日ずれるのですか?
.ics ファイルは時刻を3つの方法で表現でき、原因はほぼ必ずこのうちどれかを間違って使っていることにあります。フロート時刻(DTSTART:20260815T090000、タイムゾーンなし)は、開いた場所がどこであっても9時になります。UTC時刻(末尾のZ)は絶対的な単一の瞬間を表します。名前付きタイムゾーン(DTSTART;TZID=Europe/London:...)は、夏時間の切り替えをまたいでも同じローカル時計の時刻を保ち続ける瞬間を表します。1時間ずれてインポートされる場合、たいていは「GMT Standard Time」のようなWindows形式のタイムゾーン名が原因で、読み込むカレンダーがそれを認識できずUTCにフォールバックしています。1日ずれる終日イベントは、たいていVALUE=DATEが必要な場面で真夜中のタイムスタンプが使われているか、DTENDは排他的であるにもかかわらず、終了日が翌日ではなく最終日そのものに書かれていることが原因です。ICS Makerはデフォルトでフロート時刻を書き出し、タイムゾーンを選択した場合はIANAのタイムゾーン名を指定するTZIDを書き出します — VTIMEZONEブロックは同梱されませんが、主要なカレンダーはいずれもタイムゾーン名自体からこれを解決できます。
ファイルが「いつ」を表現する3つの方法
- フロート — タイムゾーンなし
DTSTART:20260815T090000。開いた場所がどこであっても午前9時になります。地域の予定やリマインダーなど、読む側自身の時計によって定義されるものには適していますが、異なる国にいる2人が待ち合わせる必要が生じた瞬間に問題になります。- UTC — 絶対的な瞬間
DTSTART:20260815T090000Z、末尾にZが付きます。開くもの側でローカル時刻に変換される、時間軸上の一つの瞬間です。曖昧さはありませんが、「ロンドンの10時」だったという事実が失われるため、夏時間の切り替えでずれが生じます。- 名前付きタイムゾーン — 夏時間を越えても保たれる瞬間
DTSTART;TZID=Europe/London:20260815T090000。定例会議に求められているのはこれです。オフセットが背後で変化しても、シリーズはローカルの10時に保たれ続けます。RFC 5545では、そのタイムゾーンのオフセットを定義する対応するVTIMEZONEブロックを併記することが求められています。
このビルダーはデフォルトで1つ目の方式を書き出し、一覧からタイムゾーンを選ぶと3つ目の方式を書き出します。このデフォルトは意図的なものです。9時の歯医者の予約は9時であるべきで、たまたまファイルを作成したマシンのタイムゾーンを付けてしまうと、それを読む人にとってイベントが1時間ずれる結果になります。
TZIDは同梱のVTIMEZONEブロックなしで書き出されます。これは、ファイルをどこか特殊な相手に送る前に知っておく価値があります。Apple Calendar、Google Calendar、Outlook、ThunderbirdはいずれもIANAのタイムゾーンデータベースを保持しており、名前だけからEurope/Londonを解決できるため、そのブロックは読み手がすでに知っていることを何百行にもわたって繰り返すだけのものになります。ファイル自体に定義されたタイムゾーンしか解決しない厳密なパーサーは、この割り切りが割に合わないケースです。そうしたパーサーに読み込ませる場合は、VTIMEZONEブロックを手動で貼り付けてください。
間違って届いたファイルを読む
テキストエディタで開いてDTSTARTの行を確認してください。答えは必ずそこにあります。末尾に予期しないオフセットのZが付いている場合、送信者は共有していないタイムゾーンからUTCに変換したことを意味します。Europe/LondonではなくGMT Standard Timeのような名前を持つTZIDはMicrosoft Exchangeの表記法であり、IANA名しか認識しないカレンダーはUTCにフォールバックすることがあります — これが典型的な1時間ずれのインポートです。IANA名でもなく、同じファイル内のVTIMEZONEブロックでも定義されていないタイムゾーンを指定するTZIDは、読み手ごとに解釈がまちまちになるケースであり、UTCと推測されることが多いため、2番目に確認すべき点です。
1日ずれる終日イベント
終日イベントは時刻ではなく日付です: DTSTART;VALUE=DATE:20260815。代わりに真夜中のタイムスタンプとして書かれると、それは実際の瞬間になってしまい、西方向への変換によって前日にずれ込みます。終了日はもう一つの落とし穴です。これは排他的であるため、15日の1日だけのイベントは16日に終了しなければならず、15日を終了日としたファイルは一部のカレンダーではまったく表示されません。
よくある質問
- なぜカレンダーイベントが1時間ずれるのですか?
- ほとんどの場合、夏時間の不一致が原因です。ファイルが固定のUTCオフセットを指定しているか、読み込むカレンダーが認識できないWindows形式のタイムゾーン名を指定しており、読み手がUTCにフォールバックしています。DTSTARTの行を確認してください。末尾がZであれば絶対的なUTC時刻であり、TZIDを持つ場合はそのタイムゾーンがEurope/ParisのようなIANA名で記述されているか、同じファイル内のVTIMEZONEブロックで定義されている必要があります。主要なカレンダーは自身が保持するタイムゾーンデータベースからIANA名を解決するため、そのようなブロックは不要です。
- タイムゾーンは設定すべきですか、それとも空欄にすべきですか?
- イベントがローカルの時計時刻によって定義される場合 — 予定、リマインダー、どこにいても9時に始まる授業など — は空欄のままにしてください。イベントが単一の瞬間に発生し、他のタイムゾーンにいる参加者がそれを変換する必要がある場合 — 通話、ウェビナー、放送など — はタイムゾーンを設定してください。
- フロート時刻とは何ですか?
- タイムゾーンも末尾のZも持たない日時のことで、RFC 5545ではそれを読んだ場所のローカル時刻として解釈するよう定められています。人々が思う以上に正しい選択であることが多く、異なるタイムゾーンにいる2人の読み手が同じ瞬間について合意しなければならない場合には誤った選択になります。
- なぜ終日イベントが間違った日に表示されるのですか?
- 日付の値としてではなく、真夜中のタイムスタンプとして書かれているためです。真の終日イベントは時刻を一切持たないVALUE=DATEを使用するため、変換すべきものが何もありません。また、終了日は排他的であることも覚えておいてください。15日の1日だけのイベントは、DTENDが16日になります。