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
Erstelle ein Ereignis (heute, in der Sommerzeit CEST/UTC+2): 17:00 – 19:15 Uhr Berliner Zeit.
(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 ohnetimezone=/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.
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.
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:
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.
Ereignis wurde mit timezone="Europe/Berlin" und showLocalTime="true" erstellt, während der Sommerzeit (CEST).
Die .ics-Datei über „In Kalender einfügen“ heruntergeladen und in Outlook importiert.
Tatsächliches Ergebnis: Das Ereignis erscheint mit einer Stunde Versatz (z. B. wird 17:00 Uhr Berliner Zeit in Outlook als 18:00 Uhr angezeigt). Erwartetes Ergebnis: Das Ereignis sollte um 17:00 Uhr angezeigt werden, wie eingegeben.
Wir können bestätigen, dass dies konsistent und nicht nur gelegentlich bei Ereignissen während der CEST auftritt. Andere Ereignisse außerhalb der CEST sind nicht betroffen.
Wir würden uns sehr freuen, wenn dieses Problem behoben würde, da unsere Benutzer sehr empfindlich auf Fehlfunktionen reagieren
Das Problem liegt im ICS-Export und nicht in der Server-/Container-Zeitzone. Das exportierte Ereignis verwendet eine IANA-TZID wie Europe/Berlin, enthält jedoch derzeit nicht die entsprechende VTIMEZONE-Definition, die Clients wie Outlook benötigen, um die Sommerzeitregeln zuverlässig zu interpretieren.
Der PR fügt VTIMEZONE-Definitionen in zeitzonebewusste ICS-Downloads hinzu, während die bestehenden lokalen DTSTART-/DTEND-Werte beibehalten werden.
Für das Beispiel aus diesem Thema enthält der Export nun die CET/CEST-Regelungen für Europe/Berlin, sodass:
DTSTART;TZID=Europe/Berlin:20260811T170000
mit der korrekten Sommerzeit-UTC+2-Versatzzeit interpretiert werden kann, anstatt dass Outlook auf UTC+1 zurückgreift.
Ich habe auch Abdeckung für europäische und nordamerikanische DST-Regeln, einen Fall mit festem Versatz und die ungewöhnlcheren saisonalen Übergänge, die von Africa/Casablanca verwendet werden, hinzugefügt.
