カレンダー/イベントのICSエクスポート：TZID=Europe/BerlinでOutlookにインポートすると時刻が1時間ずれる

貢献 バグ
,
1

バージョン: Discourse 2026.1.5 (ESR), discourse-calendar プラグイン

概要
タイムゾーンを指定して作成された新しいイベント（timezone="Europe/Berlin" および showLocalTime="true"）は、.ics ファイルをダウンロードして Outlook (Windows) にインポートした際、+1時間 の誤った時刻が表示されます。フォーラム内での表示は正しい時刻です。影響を受けるのは、.ics ファイルを介したインポートによる新しいイベントのみです。

再現手順

  1. イベントを作成します（本日、夏時間 CEST/UTC+2 中）：ベルリン時間 17:00 – 19:15。
[event start="2026-08-11 17:00" status="public" name="testevent 2" timezone="Europe/Berlin" showLocalTime="true" end="2026-08-11 19:15"]
[/event]
  1. 「カレンダーに追加」→ .ics ファイルをダウンロードします。
  2. ファイルを Outlook にインポートします。

期待される結果: 2026年8月11日、17:00 – 19:15
実際の結果: 2026年8月11日、18:00 – 20:15 (+1時間)

ICS コンテンツ（関連部分）:

DTSTART;TZID=Europe/Berlin:20260811T170000
DTEND;TZID=Europe/Berlin:20260811T191500

（ファイルには Europe/Berlin の VTIMEZONE ブロックが含まれていません。）

分析 / 推測される原因
エクスポートは、UTC（...Z）ではなく IANA 名称の TZID=Europe/Berlin を使用してローカル時刻を指定しています。Outlook は IANA タイムゾーン名を理解せず（「W. Europe Standard Time」などの Windows 識別子を使用します）、VTIMEZONE 定義がない場合、固定オフセット UTC+1 (CET/冬時間) にフォールバックします。夏時間（CEST = UTC+2）中では、これにより正確に +1時間 のずれが生じます。クロスチェック：同じファイルを IANA タイムゾーンをネイティブに理解する Google カレンダーにインポートすると、正しい 17:00 が表示されます。

提案：ICS エクスポートは、Z を付けた UTC タイムスタンプを使用するか、DST ルールを含む完全な VTIMEZONE ブロックを生成すべきです（LOCATION is not available in full ICS export における ICS 仕様の準拠に関する議論も参照）。*

追加の観察: 同じイベントを timezone=/showLocalTime なし で作成した場合、エクスポートされた .ics は UTC を使用し、Outlook は +2時間 を表示します（17:00 UTC = 19:00 CEST であるため）。これは文書化されている UTC の動作ですが、ローカル時刻を期待するユーザーにとって、ICS エクスポート周辺のタイムゾーン処理が混乱を招いていることをさらに示しています。

「いいね！」 2
3

比較のために、以前のカレンダーのタイムゾーン動作のため、UTC ではなくローカルの IANA タイムゾーンで Discourse ホストとアプリコンテナを稼働させています。

私のホストは以下で設定されています：

timedatectl set-timezone Europe/London

そして app.yml には以下が含まれています：

- exec: ln -fs /usr/share/zoneinfo/Europe/London /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata

これにより、私のホストと Discourse コンテナの両方が Europe/London を使用し、GMT/BST の自動切り替えも含まれます。

インストールで Europe/Berlin の同等設定をテストし、結果として得られる .ics が Outlook に正しくインポートされるかどうかを確認する価値があるかもしれません：

timedatectl set-timezone Europe/Berlin

そして run: セクションで、

- exec: ln -fs /usr/share/zoneinfo/Europe/Berlin /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata

これで、ベルリンの 17:00 のイベントが 18:00 にインポートされる代わりに、期待通り 17:00 にインポートされるようになるかどうかを知りたいと思います。

そうなる場合、Discourse/コンテナのタイムゾーンがエクスポートに影響していることを示唆します。そうでない場合、欠落している VTIMEZONE/Outlook の処理はサーバーのタイムゾーンとは無関係である可能性が高いです。

4

私たちもまさに同じ問題が発生しています。

再現手順:

  • timezone="Europe/Berlin" と showLocalTime="true" を指定してイベントを作成し、かつCEST（夏時間）期間中に設定。
  • 「カレンダーに追加」から .ics ファイルをダウンロードし、Outlook にインポート。

実際の結果: イベントの時刻が +1 時間ずれて表示される（例: ベルリン時間 17:00 が Outlook では 18:00 と表示される）。
期待される結果: 入力された通り 17:00 と表示されるべき。

CEST 期間中に発生するイベントに対しては一貫してこの問題が発生し、間欠的なものではないことを確認しています。CEST 期間外の他のイベントには影響がありません。

ユーザーは不具合に対して非常に敏感なため、この問題の修正をぜひお願いいたします :see_no_evil_monkey:

5

さらに調査を進め、この問題を修正するためのPRを開きました：

問題はサーバー/コンテナのタイムゾーンではなく、ICSエクスポートにあります。エクスポートされるイベントは Europe/Berlin のようなIANA TZID を使用していますが、Outlookなどのクライアントが夏時間ルールを確実に解釈するために必要な対応する VTIMEZONE 定義が含まれていません。

このPRでは、タイムゾーン対応のICSダウンロードに VTIMEZONE 定義を追加するとともに、既存のローカル DTSTART/DTEND 値を維持しています。

このトピックの例では、エクスポートに Europe/Berlin のCET/CESTの観測（適用）が含まれるようになったため：

DTSTART;TZID=Europe/Berlin:20260811T170000

は、OutlookがUTC+1にフォールバックするのではなく、正しいUTC+2の夏時間オフセットで解釈できます。

また、欧州および北米の夏時間ルール、固定オフセットのケース、および Africa/Casablanca で使用されるより特殊な季節の移行についてもカバレッジを追加しました。

「いいね！」 2
6

@Michael_D @Tonja 修正がマージされました。まもなく latest に反映されるはずです :+1:

「いいね！」 1
7

あなたがタイピングしている間、パイプラインを監視していました。修正が latest に反映されました。貢献ありがとうございます @Ethsim2!

「いいね！」 1
9

@Ethsim2 と @tannerabread、本当にありがとう :partying_face:

「いいね！」 2