ICS-Export für Kalender/Event: Falsche Zeit (+1 h) beim Import in Outlook mit TZID=Europe/Berlin

Beitragen Fehler
1

Version: Discourse 2026.1.5 (ESR), discourse-calendar plugin

Zusammenfassung
Neue Ereignisse, die mit einer festgelegten Zeitzone (timezone="Europe/Berlin" und showLocalTime="true") erstellt wurden, zeigen beim Herunterladen der .ics-Datei und Import in Outlook (Windows) eine um +1 Stunde falsche Zeit an. Die Zeit ist im Forum selbst korrekt. Nur neue Ereignisse sind betroffen, d. h. der Import über die .ics-Datei.

Reproduktion

  1. Erstelle ein Ereignis (heute, in der Sommerzeit CEST/UTC+2): 17:00 – 19:15 Uhr Berliner Zeit.
[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. „Zum Kalender hinzufügen“ → .ics-Datei herunterladen.
  2. Datei in Outlook importieren.

Erwartet: 11.08.2026, 17:00 – 19:15
Tatsächlich: 11.08.2026, 18:00 – 20:15 (+1 Stunde)

ICS-Inhalt (relevant):

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

(Die Datei enthält keinen VTIMEZONE-Block für Europe/Berlin.)

Analyse / Verdächtiger Grund
Der Export gibt die Zeit lokal mit TZID=Europe/Berlin (IANA-Name) anstelle von UTC (...Z) an. Outlook versteht IANA-Zeitzone-Namen nicht (es verwendet Windows-Identifikatoren wie „W. Europe Standard Time“) und fällt ohne eine VTIMEZONE-Definition auf den festen Offset UTC+1 (MEZ/Winterzeit) zurück. Während der Sommerzeit (MESZ = UTC+2) führt dies zu genau +1 Stunde. Kreuzprüfung: Der Import derselben Datei in Google Calendar (der IANA-Zeitzone nativ versteht) zeigt die korrekte Zeit 17:00 an.

Vorschlag: Der ICS-Export sollte entweder UTC-Zeitstempel mit Z verwenden oder einen vollständigen VTIMEZONE-Block einschließlich DST-Regeln generieren (siehe auch die Diskussion zur Einhaltung der ICS-Spezifikation in LOCATION is not available in full ICS export).

Zusätzliche Beobachtung: Wenn dasselbe Ereignis ohne timezone=/showLocalTime erstellt wird, verwendet die exportierte .ics UTC und Outlook zeigt +2 Stunden an (da 17:00 UTC = 19:00 MESZ). Dies ist das dokumentierte UTC-Verhalten, verdeutlicht jedoch, dass die Zeitzone-Handhabung beim ICS-Export für Benutzer, die lokale Zeiten erwarten, verwirrend ist.

3

Zum Vergleich habe ich meinen Discourse-Host und den App-Container in der lokalen IANA-Zeitzone statt in UTC betrieben, aufgrund des früheren Verhaltens bei Kalender-Zeitzone.

Mein Host ist mit folgendem Befehl eingestellt:

timedatectl set-timezone Europe/London

und meine app.yml enthält:

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

Das bedeutet, dass sowohl mein Host als auch der Discourse-Container die Zeitzone Europe/London verwenden, einschließlich des automatischen Wechsels zwischen GMT und BST.

Es könnte sinnvoll sein, das Äquivalente mit Europe/Berlin in Ihrer Installation zu testen, um zu sehen, ob die resultierenden .ics-Dateien korrekt in Outlook importiert werden:

timedatectl set-timezone Europe/Berlin

und im run:-Abschnitt:

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

Ich wäre daran interessiert zu erfahren, ob dies dazu führt, dass Ihr 17:00-Uhr-Event in Berlin statt um 18:00 wie erwartet um 17:00 importiert wird.

Wenn dem so ist, würde das darauf hindeuten, dass die Zeitzone von Discourse/Container den Export beeinflusst; wenn nicht, ist das fehlende VTIMEZONE/Outlook-Handling wahrscheinlich unabhängig von der Server-Zeitzone.