I’ve investigated this further and opened a PR to address it:
The issue is in the ICS export rather than the server/container timezone. The exported event uses an IANA TZID such as Europe/Berlin, but currently doesn’t include the corresponding VTIMEZONE definition that clients such as Outlook need to interpret the daylight-saving rules reliably.
The PR adds VTIMEZONE definitions to timezone-aware ICS downloads while keeping the existing local DTSTART/DTEND values.
For the example from this topic, the export now includes the CET/CEST observances for Europe/Berlin, so:
DTSTART;TZID=Europe/Berlin:20260811T170000
can be interpreted with the correct UTC+2 summer offset rather than Outlook falling back to UTC+1.
I’ve also added coverage for European and North American DST rules, a fixed-offset case, and the more unusual seasonal transitions used by Africa/Casablanca.