Version : Discourse 2026.1.5 (ESR), plugin discourse-calendar
Résumé
Les nouveaux événements créés avec un fuseau horaire défini (timezone="Europe/Berlin" et showLocalTime="true") affichent une heure incorrecte, en avance de +1 heure, lors du téléchargement du fichier .ics et de son importation dans Outlook (Windows). L’heure est correcte sur le forum lui-même. Seuls les nouveaux événements sont concernés, c’est-à-dire l’importation via le fichier .ics.
Reproduction
Créer un événement (aujourd’hui, en heure d’été CEST/UTC+2) : 17h00 – 19h15 heure de Berlin.
(Le fichier ne contient pas de bloc VTIMEZONE pour Europe/Berlin.)
Analyse / Cause suspectée
L’exportation spécifie l’heure localement avec TZID=Europe/Berlin (nom IANA) au lieu de l’UTC (...Z). Outlook ne comprend pas les noms de fuseaux horaires IANA (il utilise des identifiants Windows tels que « W. Europe Standard Time ») et, en l’absence de définition VTIMEZONE, utilise le décalage fixe UTC+1 (CET/heure d’hiver). Pendant l’heure d’été (CEST = UTC+2), cela entraîne exactement un décalage de +1 heure. Vérification croisée : l’importation du même fichier dans Google Calendar (qui comprend nativement les fuseaux horaires IANA) affiche correctement 17h00.
Suggestion : l’exportation ICS devrait soit utiliser des horodatages UTC avec Z, soit générer un bloc VTIMEZONE complet incluant les règles d’heure d’été (voir également la discussion sur la conformité à la spécification ICS dans LOCATION n’est pas disponible dans l’exportation ICS complète).
Observation supplémentaire : Lorsque le même événement est créé sanstimezone=/showLocalTime, le fichier .ics exporté utilise l’UTC et Outlook affiche +2 heures (puisque 17h00 UTC = 19h00 CEST). C’est le comportement UTC documenté, mais cela illustre davantage que la gestion des fuseaux horaires autour de l’exportation ICS est confuse pour les utilisateurs qui s’attendent à voir des heures locales.
Pour comparaison, j’ai exécuté mon hôte Discourse et mon conteneur d’application dans le fuseau horaire IANA local plutôt qu’en UTC, en raison du comportement précédent des fuseaux horaires du calendrier.
Cela signifie que mon hôte et mon conteneur Discourse utilisent tous deux Europe/London, y compris le changement automatique GMT/BST.
Il pourrait être intéressant de tester l’équivalent avec Europe/Berlin sur votre installation pour voir si le fichier .ics résultant est correctement importé dans Outlook :
Je serais curieux de savoir si cela modifie l’importation de votre événement de 17h00 à Berlin, qui passait de 18h00 à l’heure attendue de 17h00.
Si c’est le cas, cela suggérerait que le fuseau horaire de Discourse/du conteneur influence l’exportation ; si ce n’est pas le cas, l’absence de VTIMEZONE/la gestion par Outlook est probablement indépendante du fuseau horaire du serveur.
Événement créé avec timezone="Europe/Berlin" et showLocalTime="true", pendant la CEST (heure d’été).
Fichier .ics téléchargé via « Ajouter au calendrier » et importé dans Outlook.
Résultat actuel : L’événement apparaît avec un décalage de +1 heure (par exemple, 17:00 heure de Berlin s’affiche comme 18:00 dans Outlook). Résultat attendu : L’événement devrait s’afficher à 17:00, comme saisi.
Nous pouvons confirmer que ce problème se produit de manière constante, et non de façon intermittente, pour les événements ayant lieu pendant la CEST. Les autres événements en dehors de la CEST ne sont pas affectés.
Nous serions ravis de voir ce problème corrigé, car nos utilisateurs peuvent être très sensibles aux dysfonctionnements
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.
