J’ai approfondi l’investigation et ouvert une PR pour y remédier :
Le problème se situe dans l’export ICS, et non dans le fuseau horaire du serveur/conteneur. L’événement exporté utilise un TZID IANA tel que Europe/Berlin, mais ne contient actuellement pas la définition VTIMEZONE correspondante dont des clients comme Outlook ont besoin pour interpréter de manière fiable les règles de l’heure d’été.
La PR ajoute des définitions VTIMEZONE aux téléchargements ICS sensibles au fuseau horaire, tout en conservant les valeurs locales existantes de DTSTART/DTEND.
Pour l’exemple de ce sujet, l’export inclut désormais les observances CET/CEST pour Europe/Berlin, de sorte que :
DTSTART;TZID=Europe/Berlin:20260811T170000
peut être interprété avec le décalage d’été UTC+2 correct, au lieu que Outlook bascule sur UTC+1.
J’ai également ajouté une couverture pour les règles d’heure d’été en Europe et en Amérique du Nord, un cas de décalage fixe, ainsi que les transitions saisonnières plus inhabituelles utilisées par Africa/Casablanca.