Ho approfondito l’indagine e ho aperto una PR per risolvere il problema:
Il problema si trova nell’esportazione ICS, non nel fuso orario del server/contenitore. L’evento esportato utilizza un TZID IANA come Europe/Berlin, ma attualmente non include la definizione corrispondente di VTIMEZONE di cui hanno bisogno client come Outlook per interpretare in modo affidabile le regole dell’ora legale.
La PR aggiunge definizioni VTIMEZONE ai download ICS con supporto per i fusi orari, mantenendo i valori locali esistenti di DTSTART/DTEND.
Per l’esempio in questo topic, l’esportazione ora include le osservanze CET/CEST per Europe/Berlin, quindi:
DTSTART;TZID=Europe/Berlin:20260811T170000
può essere interpretato con il corretto offset estivo UTC+2, anziché far sì che Outlook cada sul fallback UTC+1.
Ho anche aggiunto la copertura per le regole dell’ora legale europee e nordamericane, un caso con offset fisso e le transizioni stagionali più insolite utilizzate da Africa/Casablanca.