Invitations iCalendar : UID, SEQUENCE et bien gérer les fuseaux horaires

Ce que c'est

iCalendar (RFC 5545, type de média text/calendar) décrit les événements sous forme de composants VEVENT à l'intérieur d'un VCALENDAR. iTIP (RFC 5546) définit la façon dont ils sont échangés : METHOD:REQUEST de la part de l'organisateur, METHOD:REPLY de la part des participants avec un PARTSTAT (accepté, refusé, provisoire), METHOD:CANCEL pour retirer l'événement. Un événement est identifié à travers tous les messages par UID ; une révision par SEQUENCE, que l'organisateur doit incrémenter lorsqu'il modifie DTSTART, DTEND, DURATION, RRULE et des propriétés similaires. Les horaires se présentent sous trois formes : en UTC (20260916T090000Z), en heure locale avec un paramètre TZID renvoyant à un composant VTIMEZONE du même objet (DTSTART;TZID=Europe/Zurich:20260916T110000), et en heure flottante sans aucun des deux, ce qui signifie « 11h00 où que se trouve le lecteur ». La RFC 5545 exige un VTIMEZONE pour chaque TZID utilisé et avertit que son omission conduit à une interprétation incohérente de l'heure locale.

Pourquoi c'est important

Une invitation qui se retrouve décalée d'une heure après un changement d'heure d'été, ou qui crée un doublon à chaque mise à jour, est pire que pas d'invitation du tout. Les calendriers sont l'un des endroits où « stocker en UTC » ne suffit pas : une réunion hebdomadaire à 09h00 à Zurich doit rester à 09h00 en heure locale à travers les transitions de mars et d'octobre, ce que seule une heure locale ancrée à un fuseau exprime.

Comment l'appliquer

• Générer un UID stable par événement, le stocker, le réutiliser dans chaque mise à jour et annulation, et incrémenter SEQUENCE à chaque changement substantiel ; DTSTAMP est l'heure du message, pas le compteur de révision.
• Utiliser TZID avec des noms de fuseau IANA et intégrer un VTIMEZONE correct (avec des règles STANDARD et DAYLIGHT) issu d'une bibliothèque maintenue. Utiliser l'UTC pour les événements ponctuels dont les participants sont répartis sur plusieurs fuseaux, et l'heure flottante uniquement pour ce qui suit réellement l'horloge murale du lecteur ; les événements sur toute la journée utilisent une valeur DATE (DTSTART;VALUE=DATE:20260916) plutôt qu'un minuit flottant.
• Pour les événements récurrents, suivre la RFC 5545 : lorsque DTSTART porte un TZID, la partie UNTIL de la règle doit être en UTC. Modifier des occurrences isolées avec RECURRENCE-ID plutôt que d'éditer la série.
• Envoyer les invitations sous forme d'une partie text/calendar avec le paramètre method renseigné (method=REQUEST), et ajouter le même objet en pièce jointe .ics pour les clients qui ignorent ce paramètre.
• Tester l'aller-retour complet avec au moins deux familles de clients à travers une frontière de changement d'heure, y compris une mise à jour et une annulation.

Pièges

Un nouvel UID à chaque mise à jour (doublons). Des noms de fuseau qui ne sont pas des identifiants IANA, que les autres clients ne peuvent pas faire correspondre. Annuler avec STATUS:CANCELLED mais sans METHOD:CANCEL. Des événements sur toute la journée envoyés en UTC de minuit à minuit, qui se décalent d'un jour dans d'autres fuseaux. Envoyer un CANCEL sans incrémenter SEQUENCE, ce qu'exige pourtant la RFC 5546.