ICS MakerMauvais fuseau horaire

Quand l'événement tombe à la mauvaise heure

Presque tous les problèmes du type « l'invitation est décalée d'une heure » se résument à l'une de ces trois causes : une heure sans fuseau, un fuseau que le calendrier qui la lit ne reconnaît pas, ou un événement toute la journée traité comme un événement à heure fixe.

Titre, lieu, date et heure, fuseau horaire, récurrence, invités, alertes et notes — téléchargez ensuite le fichier .ics ou ouvrez-le directement dans votre calendrier. Vous pouvez aussi coller un programme ou joindre un document ou une photo pour créer plusieurs événements à la fois.

Pourquoi mon événement de calendrier est-il décalé d'une heure, ou d'un jour ?

Un fichier .ics peut exprimer une heure de trois façons, et c'est presque toujours la mauvaise qui en est la cause. Une heure flottante (DTSTART:20260815T090000, sans fuseau) est neuf heures là où elle est ouverte. Une heure UTC (un Z final) est un instant absolu. Un fuseau nommé (DTSTART;TZID=Europe/London:...) est un instant qui reste à la même heure locale malgré le changement d'heure d'été/hiver. Un import décalé d'une heure vient généralement d'un nom de fuseau de style Windows tel que « GMT Standard Time » que le calendrier qui le lit ne reconnaît pas et qu'il ramène par défaut à UTC ; un événement décalé d'un jour est généralement un horodatage à minuit alors qu'il fallait VALUE=DATE, ou une date de fin écrite le dernier jour au lieu du lendemain, puisque DTEND est exclusif. ICS Maker écrit par défaut une heure flottante, et un TZID nommant un fuseau IANA lorsqu'un fuseau est choisi — sans bloc VTIMEZONE intégré, que tout calendrier grand public résout à partir du nom du fuseau lui-même.

Les trois façons dont un fichier peut dire quand

Flottante — aucun fuseau du tout
DTSTART:20260815T090000. Neuf heures du matin là où c'est ouvert. Adapté à un rendez-vous local, un rappel, ou tout ce qui est défini par l'horloge propre du lecteur ; inadapté dès que deux personnes dans des pays différents doivent se retrouver.
UTC — un instant absolu
DTSTART:20260815T090000Z, avec le Z final. Un instant précis, converti en heure locale par ce qui l'ouvre. Sans ambiguïté, mais cela perd le fait que la réunion était « dix heures à Londres », si bien qu'un changement d'heure la déplace.
Fuseau nommé — un instant qui survit au changement d'heure
DTSTART;TZID=Europe/London:20260815T090000. Ce que veut une réunion récurrente : la série reste à dix heures locales même si le décalage change sous ses pieds. La RFC 5545 demande un bloc VTIMEZONE correspondant, définissant les décalages de ce fuseau à ses côtés.

Ce générateur écrit la première par défaut, et la troisième lorsque vous choisissez un fuseau dans la liste. Ce choix par défaut est délibéré : un rendez-vous chez le dentiste à neuf heures doit rester à neuf heures, et attacher le fuseau de la machine qui a construit le fichier est justement ce qui fait qu'un événement se retrouve décalé d'une heure pour la personne qui le lit.

Il écrit le TZID sans bloc VTIMEZONE intégré, ce qui vaut la peine d'être su avant d'envoyer le fichier quelque part d'inhabituel. Apple Calendar, Google Calendar, Outlook et Thunderbird embarquent tous la base de données IANA des fuseaux horaires et résolvent Europe/London à partir du seul nom, si bien que ce bloc représenterait plusieurs centaines de lignes reformulant ce que le lecteur sait déjà. Un analyseur strict qui ne résout que les fuseaux définis dans le fichier lui-même est le cas où ce compromis ne tient pas — collez un bloc VTIMEZONE à la main si c'est ce que vous alimentez.

Lire un fichier arrivé décalé

Ouvrez-le dans un éditeur de texte et regardez la ligne DTSTART, car la réponse s'y trouve toujours. Un Z final avec un décalage inattendu signifie que l'expéditeur a converti en UTC depuis un fuseau que vous ne partagez pas. Un TZID nommant quelque chose comme GMT Standard Time plutôt que Europe/London est l'orthographe propre à Microsoft Exchange, et les calendriers qui ne connaissent que les noms IANA peuvent alors basculer par défaut sur UTC — ce qui est le classique import décalé d'une heure. Un TZID nommant un fuseau qui n'est ni un nom IANA ni défini par un bloc VTIMEZONE dans le même fichier est le cas où chaque lecteur devine à sa façon, et devine assez souvent UTC pour que ce soit le deuxième point à vérifier.

L'événement toute la journée qui se déplace d'un jour

Un événement toute la journée est une date, pas une heure : DTSTART;VALUE=DATE:20260815. Écrit comme un horodatage à minuit à la place, il devient un instant réel, et toute conversion vers l'ouest le fait basculer dans la veille. La date de fin est l'autre piège — elle est exclusive, si bien qu'un seul jour le 15 se termine le 16, et un fichier qui le termine le 15 n'affiche rien du tout dans certains calendriers.

Questions

Pourquoi mon événement de calendrier est-il décalé d'une heure ?
Presque toujours un décalage lié au changement d'heure : le fichier indique un décalage UTC fixe, ou un nom de fuseau de style Windows que le calendrier qui le lit ne reconnaît pas, et le lecteur bascule par défaut sur UTC. Vérifiez la ligne DTSTART — si elle se termine par Z, l'heure est un UTC absolu, et si elle porte un TZID, ce fuseau doit être orthographié comme un nom IANA tel que Europe/Paris, ou bien être défini par un bloc VTIMEZONE dans le même fichier. Les calendriers grand public résolvent le nom IANA à partir de leur propre copie de la base de données des fuseaux horaires et n'ont besoin d'aucun bloc de ce type.
Dois-je définir un fuseau horaire ou le laisser vide ?
Laissez-le vide lorsque l'événement est défini par l'heure locale de l'horloge — un rendez-vous, un rappel, un cours qui commence à neuf heures où que vous soyez. Définissez-en un lorsque l'événement se produit à un instant unique que des invités dans d'autres fuseaux doivent convertir, comme un appel, un webinaire, ou une diffusion.
Qu'est-ce qu'une heure flottante ?
Une date-heure écrite sans fuseau et sans Z final, que la RFC 5545 indique devoir être interprétée comme l'heure locale là où elle est lue. C'est le bon choix plus souvent qu'on ne s'y attend, et le mauvais dès que deux lecteurs dans des fuseaux différents doivent s'accorder sur un instant.
Pourquoi mon événement toute la journée apparaît-il le mauvais jour ?
Parce qu'il a été écrit comme un horodatage à minuit plutôt que comme une valeur de date. Un véritable événement toute la journée utilise VALUE=DATE sans aucune heure, si bien qu'il n'y a rien à convertir. N'oubliez pas non plus que la date de fin est exclusive : un événement d'un seul jour le 15 a son DTEND le 16.