Le même fichier .ics peut désigner cinq heures différentes

Pourquoi le fichier nomme un fuseau plutôt qu'un décalage

Écrire +02:00 fixerait la réunion à un nombre qui cesse d'être vrai deux fois par an. Un rendez-vous hebdomadaire à 14h00 à Paris vaut +02:00 en septembre et +01:00 en novembre, et tout l'intérêt d'un événement récurrent est qu'il reste à quatorze heures des deux côtés du changement. Nommer Europe/Paris dit quel règlement appliquer ; le décalage se lit ensuite, date par date, dans une base de fuseaux mise à jour chaque fois qu'un pays déplace ses pendules.

C'est aussi pourquoi convertir une heure TZID en UTC n'est pas une soustraction qu'on fait de tête, et pourquoi un outil sans base de fuseaux ne devrait pas s'y risquer. Garder le nom et les chiffres de pendule exactement comme le fichier les a écrits ne perd rien ; les remplacer par un instant calculé depuis le mauvais fuseau, si — et c'est le genre d'erreur qui paraît normale à l'écran jusqu'à ce que quelqu'un rejoigne une visio avec une heure de retard.

L'événement d'une journée, qui n'est pas une heure

Un anniversaire, un jour férié ou un jour de congé s'écrit DTSTART;VALUE=DATE:20261225 — huit chiffres, pas d'heure, et le paramètre qui le dit. Cela signifie tout le 25 décembre là où se trouve le lecteur, ce qui est exactement juste pour Noël et serait faux comme instant. Réécris-le en date-heure et il devient minuit UTC, soit encore le 25 en Europe et déjà le 24 partout à l'ouest de Greenwich. Le marqueur VALUE=DATE est transmis tel quel ici, plutôt que résolu en une heure.

Ce qu'il faut vérifier avant de se fier à un agenda importé

Ouvre le fichier dans le visualiseur et regarde un événement dont tu connais l'heure réelle. Si elle est juste là, le fichier est juste, et tout désaccord ultérieur vient de l'application dans laquelle tu as importé. Trois habitudes couvrent presque tout : préfère la forme Z quand tu publies un agenda auquel d'autres s'abonneront, garde le TZID quand tu déplaces ton propre agenda d'une application à l'autre, et ne modifie jamais une heure de début à la main dans un éditeur de texte sans regarder dans laquelle des trois formes la ligne est écrite.

Questions fréquentes

Mes événements importés sont tous décalés d'une ou deux heures. Que s'est-il passé ?

Un décalage constant sur tous les événements est la signature d'un fuseau retiré puis remplacé. Ouvre le .ics d'origine dans le visualiseur : si les heures de début y semblent justes, le fichier a gardé son fuseau et c'est l'application d'import qui en applique un autre — vérifie son réglage de fuseau d'agenda, distinct de celui du système. Un décalage qui varie d'un événement à l'autre est un autre problème, en général un mélange d'heures Z et flottantes dans un même fichier.

Quelle forme utiliser quand je publie un agenda ?

Z pour tout ce qui a un instant fixe — un webinaire, un match, une échéance — parce que rien ne peut le mal lire et qu'aucune base de fuseaux n'est nécessaire à l'arrivée. TZID pour un agenda que des gens vivent localement, comme un emploi du temps scolaire ou les horaires d'un bureau, où c'est l'heure de pendule qui doit rester en place au changement d'heure. VALUE=DATE pour les journées entières. Les heures flottantes seulement quand tu veux vraiment dire l'heure locale partout, ce qui en pratique se limite au Nouvel An ou presque.

Le visualiseur modifie-t-il mon fichier ?

Non. Il lit le fichier dans ton navigateur et montre ce qu'il contient ; le fichier sur le disque n'est pas touché, et rien n'est envoyé nulle part. C'est tout l'intérêt de regarder avant de convertir : tu peux trancher une discussion sur une heure de début sans t'engager à quoi que ce soit.