Les problèmes de fuseaux horaires dans les calendriers se ressemblent souvent. Vous voyez la réunion à 09:00, tandis que la personne invitée la voit à 15:00. Ce décalage peut être normal, mais il arrive aussi que les invitations désignent des instants différents. Ou tout fonctionne pendant plusieurs semaines, puis la réunion se décale d'une heure après le changement d'heure. Ou le rappel arrive pendant votre sommeil.
Le problème ne vient pas toujours de l'affichage. L'événement a été enregistré comme « 9 heures », sans préciser dans quel fuseau se situent ces 9 heures. Les composants qui utilisent cette valeur complètent l'information manquante chacun à leur manière et n'aboutissent pas au même résultat.
Voici comment un calendrier représente les fuseaux horaires, pourquoi une erreur peut rester cachée pendant des semaines et ce que change l'enregistrement du fuseau avec l'heure de l'événement.
Le problème d'une heure sans fuseau
Supposons qu'un calendrier enregistre le début d'une réunion sous la forme 2026-09-14 09:00, sans autre information. Pour une réunion partagée, cette valeur est ambiguë : plusieurs composants peuvent lui donner des sens différents.
Le formulaire du navigateur transmet l'heure saisie. Un client CalDAV ajoute un identifiant de fuseau, mais si le serveur l'ignore, il ne conserve que l'heure locale. À l'export, cette valeur peut être marquée à tort comme UTC, parce que le format attend une représentation définie. Le service de rappels, lui, compare la valeur enregistrée à l'heure actuelle en UTC.
Quatre composants, quatre interprétations d'une même donnée. Si tout le monde utilise UTC, le défaut peut passer inaperçu. Il suffit d'ajouter une personne à Berlin pour que certains événements soient traités différemment, sans message d'erreur.
Ce défaut est facile à manquer lorsque les tests restent dans un seul fuseau. Des essais avec plusieurs régions permettent de le repérer plus tôt. Sinon, il apparaît lors d'un voyage, d'un changement d'heure ou de la première invitation envoyée à quelqu'un dans un autre fuseau.
Trois façons de représenter l'heure dans un calendrier
Le standard iCalendar, utilisé pour échanger des événements entre de nombreux calendriers, distingue plusieurs représentations des dates et des heures. Pour les événements avec une heure précise, voici les principaux cas.| Type | Exemple | Signification | Usage adapté |
|---|---|---|---|
| UTC | 20260914T070000Z | Un instant précis, identique partout | Une réunion entre personnes de régions différentes |
| Heure avec fuseau | TZID=Europe/Berlin:20260914T090000 | 9 heures à Berlin, avec conversion pour les autres | Un événement lié à son lieu de tenue |
| Heure flottante | 20260914T090000 | 9 heures selon l'horloge locale de chaque personne | Des rappels personnels qui doivent suivre l'heure locale |
L'heure flottante est valable lorsque ce comportement est voulu. En revanche, un anniversaire, par exemple le 14, se représente généralement par une date, pas par une heure flottante. Pour une réunion commune, des heures locales identiques peuvent désigner des instants différents.
Les événements sur toute la journée sont enregistrés comme des dates, sans conversion entre fuseaux. Si l'on transforme un jour férié en instant UTC avant de le reconvertir, il peut apparaître la veille au soir à l'ouest de Greenwich. Une date ne doit donc pas être traitée comme l'heure de début d'une réunion.
Pourquoi le changement d'heure révèle les erreurs
Les fuseaux seraient plus simples si leur décalage par rapport à UTC restait constant. Ce n'est pas le cas dans de nombreuses régions, et les transitions révèlent des erreurs jusque-là invisibles.
Berlin utilise UTC+1 en hiver et UTC+2 en été. Si une réunion récurrente est calculée à une heure UTC fixe, elle se décale sur l'horloge locale après la transition : l'instant est bien défini, mais ce n'est plus la réunion de 9 heures. Pour qu'une série associée à Europe/Berlin reste à 9 heures, ses occurrences doivent aussi être calculées dans ce fuseau. Enregistrer uniquement son nom ne suffit pas.
La situation se complique entre pays, car l'Europe et l'Amérique du Nord ne changent pas d'heure aux mêmes dates. Entre les transitions, le décalage habituel entre Londres et New York varie d'une heure. La durée de cet intervalle dépend de la saison et de l'année : elle n'est pas toujours identique. Une réunion peut donc changer temporairement d'heure locale pour une partie des participants sans que le calendrier soit défectueux.
Choisir un autre fuseau par défaut ne supprime pas cette différence. « Le même instant » et « La même heure locale » sont deux exigences distinctes. Il faut choisir le comportement de la série et vérifier que le calcul des occurrences et les échanges avec les clients le conservent.
Enregistrer UTC avec le fuseau horaire
Pour un événement avec une heure précise, il est utile de garder les deux informations : l'instant UTC et le fuseau dans lequel l'heure locale a été saisie. Pour une série récurrente, la manière de calculer les occurrences compte aussi.
UTC permet de comparer les instants, de trier les événements et de détecter les chevauchements sans ambiguïté. Le fuseau explique l'heure locale d'origine. Mais conserver ce champ ne garantit pas que chaque export transmettra toutes les propriétés de la série : il faut vérifier le format produit et le comportement du client.
En pratique :
- Créer un événement dans le webmail transmet le fuseau du navigateur avec l'heure saisie. Le serveur convertit cette heure en UTC et enregistre le fuseau. Si le navigateur est réglé sur Berlin, ce sera le fuseau conservé.
- Le consulter ailleurs convertit UTC vers l'heure locale du navigateur. À la date de l'exemple, Berlin affiche 09:00 et San Francisco 00:00. Ces valeurs désignent le même instant ; les décalages peuvent différer à d'autres périodes.
- Les rappels disposent d'un instant sans ambiguïté pour la comparaison. Le fuseau ne crée plus cette incertitude, mais l'envoi dépend toujours du bon fonctionnement du planificateur et des canaux de notification.
- Modifier un événement affiche l'heure dans le fuseau du navigateur actuel, pas nécessairement dans le fuseau d'origine. Vérifiez l'heure et les réglages de l'appareil avant d'enregistrer, surtout après un déplacement.
Le devenir des anciens événements
Les anciens événements peuvent ne pas avoir de fuseau enregistré. Ils ne sont pas réinterprétés automatiquement : l'interface web conserve leur ancien mode d'affichage. Cela évite de déplacer des rendez-vous existants sans prévenir.
Ce choix est volontaire. Attribuer un fuseau après coup revient à le deviner, et une mauvaise supposition déplace les rendez-vous sans accord. Si un événement affiche 14:00 depuis deux ans, une correction automatique ne devrait pas lui attribuer une autre heure. Lors d'une vérification manuelle, déterminez d'abord ce que signifiait ce 14:00.
Vous pouvez ajouter un fuseau à un ancien événement en le modifiant. Le webmail transmet le fuseau du navigateur lorsque vous enregistrez un événement avec une heure : vérifiez d'abord l'heure locale et les réglages de l'appareil. Modifier seulement la description par API, sans paramètre de fuseau, n'ajoute pas cette information. Les événements laissés intacts gardent leur ancien comportement.
Si une ancienne réunion récurrente s'affiche mal pour des participants à l'étranger, vérifiez son heure et son fuseau d'origine, puis enregistrez la correction. Contrôlez ensuite les occurrences avant et après le changement d'heure : un nouvel enregistrement ne garantit pas à lui seul le bon calcul de toute la série.
CalDAV, ICS et les autres calendriers
Un calendrier ne devrait pas fonctionner uniquement dans son interface web. Apple Calendar, Thunderbird et des applications mobiles compatibles peuvent se connecter par CalDAV. Mais la présence de Google Calendar sur un appareil ne signifie pas qu'il peut se connecter à n'importe quel serveur CalDAV : le mode d'intégration et sa compatibilité doivent être vérifiés.
Lorsqu'un événement arrive par CalDAV, le serveur utilise l'identifiant de fuseau pour enregistrer l'instant UTC correspondant. Le document de calendrier reçu peut être renvoyé sans modification ; pour les événements créés dans le webmail, le serveur génère des valeurs UTC. Les réponses n'utilisent donc pas toutes la même représentation. Les événements sur toute la journée sont échangés comme des dates. Pour les séries récurrentes, vérifiez également si cet échange conserve l'heure locale des occurrences.
Des clients compatibles peuvent afficher le même instant : par exemple, un événement créé sur un iPhone à Berlin, modifié dans le webmail depuis un ordinateur portable à Lisbonne et ouvert dans Thunderbird à New York. Les heures locales seront différentes. Cela exige des réglages corrects sur les clients et les appareils ; les noms des fuseaux proviennent de la base de données des fuseaux horaires IANA.
Consultez les guides de configuration : Apple Calendar sur macOS, iPhone et iPad, Android avec DAVx⁵ et Thunderbird. Outlook nécessite généralement une extension tierce pour CalDAV ; les limites selon la version sont précisées dans le guide de connexion d'Outlook.
Les précautions utiles pour les fuseaux horaires
Indiquez le fuseau dans le titre d'une réunion internationale. « Réunion hebdomadaire (09:00 CET) » peut aider si le client de messagerie affiche mal l'invitation. Mais CET correspond à l'heure d'hiver ; Berlin utilise CEST en été. Choisissez l'abréviation adaptée à la date ou indiquez une ville connue des participants, plutôt que CET toute l'année.
Rattachez la série au fuseau qui détermine son horaire. Si la réunion doit suivre l'horloge du bureau de Berlin, utilisez ce fuseau et vérifiez que les occurrences y sont calculées. Pour les participants à l'étranger, l'heure locale peut changer pendant les transitions. Cela ne signifie pas forcément que la réunion a été déplacée : le décalage entre régions a pu changer.
Revérifiez les réunions importantes autour des changements d'heure. L'Europe et l'Amérique du Nord effectuent la transition à des dates différentes, ce qui modifie temporairement le décalage habituel. Vérifiez la date précise et confirmez par écrit l'heure de chaque côté.
Utilisez un événement sur toute la journée lorsque seule la date compte. Ce format convient pour marquer le jour d'une conférence. Si les participants doivent arriver à une heure précise, créez un événement avec une heure et un fuseau, pas uniquement une date. N'attribuez pas non plus d'heure arbitraire à un événement qui n'en a pas besoin.
Vérifiez les anciennes séries et, si nécessaire, enregistrez l'heure et le fuseau corrigés. L'absence de fuseau dans une ancienne entrée ne prouve pas qu'il s'agit d'une heure flottante correctement définie. Lors d'un enregistrement dans le webmail, tenez compte des réglages du navigateur. Ils méritent aussi une vérification pour l'envoi programmé, dont l'heure saisie dépend du fuseau de l'appareil.Questions fréquentes
Pourquoi ma réunion affiche-t-elle une autre heure dans un autre fuseau ?
Des heures locales différentes représentent généralement le même instant, ce qui est normal. Il y a un problème si les participants ont reçu des instants de début réellement différents. Vérifiez alors le fuseau de l'événement et les réglages des clients. Si le fuseau manquait, confirmez l'heure d'origine, enregistrez le bon fuseau et vérifiez le résultat avec les participants.
Pourquoi ma réunion récurrente s'est-elle décalée d'une heure ?
Un changement d'heure peut l'expliquer. Une série à heure UTC fixe conserve cette heure, mais change sur l'horloge locale. Une série calculée dans un fuseau local conserve l'heure locale, mais peut se décaler pour les autres régions. Le comportement souhaité dépend de votre accord ; vérifiez le calcul et l'export de la série.
Quel fuseau est utilisé quand je crée un événement dans le webmail ?
Le webmail détecte le fuseau du navigateur et le transmet pour un événement avec une heure. Le serveur enregistre l'instant UTC et le fuseau. Vérifiez les réglages de l'appareil avant la création, surtout si la réunion doit suivre un autre fuseau que le vôtre.
Les événements sur toute la journée sont-ils convertis ?
Non. Ce sont des dates, pas des instants. Convertir une date via UTC peut la faire apparaître la veille ou le lendemain pour des personnes dans d'autres fuseaux.
Que deviennent les événements créés avant l'enregistrement des fuseaux ?
Ils gardent leur ancien comportement sans attribution automatique d'un fuseau. Le webmail ajoute le fuseau du navigateur lors de l'enregistrement d'un événement avec une heure : vérifiez d'abord l'heure et les réglages de l'appareil. Une mise à jour par API sans paramètre de fuseau explicite laisse l'ancienne entrée sans fuseau.
Les fuseaux fonctionnent-ils correctement avec Apple Calendar et Google Calendar ?
Un client CalDAV compatible et bien réglé peut convertir correctement l'heure. Un guide explique comment connecter Apple Calendar. Pour Google Calendar, vérifiez le mode d'intégration disponible : une connexion à n'importe quel serveur CalDAV externe n'est pas garantie. Contrôlez aussi les occurrences et les changements d'heure.
Puis-je préciser le fuseau par API ?
Oui. L'API REST de création et de modification des événements accepte un paramètre de fuseau horaire. Pour MCP, consultez le schéma de l'outil et transmettez ce champ s'il est pris en charge. Son omission ne garantit pas que le système pourra retrouver le fuseau voulu.
Pourquoi les rappels des anciens événements arrivent-ils à la mauvaise heure ?
Si l'heure a été enregistrée sans fuseau, sa comparaison avec l'instant actuel peut donner un résultat incorrect. Confirmez l'heure d'origine, enregistrez le bon fuseau et testez le rappel. Si le problème persiste, vérifiez aussi les paramètres de notification et le fonctionnement du planificateur.
