Ich habe dies weiter untersucht und einen PR erstellt, um das Problem zu beheben:
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.