Export ICS Calendrier/Événement : heure incorrecte (+1 h) lors de l'importation dans Outlook avec TZID=Europe/Berlin

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

  1. Créer un événement (aujourd’hui, en heure d’été CEST/UTC+2) : 17h00 – 19h15 heure de Berlin.
[event start="2026-08-11 17:00" status="public" name="testevent 2" timezone="Europe/Berlin" showLocalTime="true" end="2026-08-11 19:15"]
[/event]

  1. « Ajouter au calendrier » → télécharger le fichier .ics.
  2. Importer le fichier dans Outlook.

Attendu : 11.08.2026, 17h00 – 19h15
Réel : 11.08.2026, 18h00 – 20h15 (+1 heure)

Contenu ICS (pertinent) :

DTSTART;TZID=Europe/Berlin:20260811T170000
DTEND;TZID=Europe/Berlin:20260811T191500

(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éé sans timezone=/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.

Mon hôte est configuré avec :

timedatectl set-timezone Europe/London

et mon app.yml contient :

- exec: ln -fs /usr/share/zoneinfo/Europe/London /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata

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 :

timedatectl set-timezone Europe/Berlin

et, dans la section run:,

- exec: ln -fs /usr/share/zoneinfo/Europe/Berlin /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata

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.