Invitaciones iCalendar: UID, SEQUENCE y cómo gestionar correctamente las zonas horarias

Qué es

iCalendar (RFC 5545, tipo de medio text/calendar) describe los eventos como componentes VEVENT dentro de un VCALENDAR. iTIP (RFC 5546) define cómo se intercambian: METHOD:REQUEST desde quien organiza, METHOD:REPLY desde los asistentes con un PARTSTAT (aceptado, rechazado, provisional), METHOD:CANCEL para retirar el evento. Un evento se identifica en todos los mensajes mediante UID; una revisión, mediante SEQUENCE, que quien organiza debe incrementar cuando cambian DTSTART, DTEND, DURATION, RRULE y propiedades similares. Las horas se expresan de tres formas: UTC (20260916T090000Z), hora local con un parámetro TZID que remite a un componente VTIMEZONE dentro del mismo objeto (DTSTART;TZID=Europe/Zurich:20260916T110000), y hora flotante sin ninguno de los dos, lo que significa «las 11:00 donde sea que esté quien lee». RFC 5545 exige un VTIMEZONE para cada TZID usado y advierte que omitirlo lleva a una interpretación inconsistente de la hora local.

Por qué importa

Una invitación que queda desfasada una hora tras un cambio de horario de verano, o que crea un duplicado en cada actualización, es peor que no tener ninguna. Los calendarios son uno de los lugares donde «guardar en UTC» no basta: una reunión semanal de las 09:00 en Zúrich debe permanecer a las 09:00 hora local a través de las transiciones de marzo y octubre, algo que solo una hora local anclada a una zona expresa.

Cómo aplicarlo

• Generar un UID estable por evento, almacenarlo, reutilizarlo en cada actualización y cancelación, e incrementar SEQUENCE en cada cambio sustancial; DTSTAMP es la hora del mensaje, no el contador de revisión.
• Usar TZID con nombres de zona IANA e incrustar un VTIMEZONE correcto (con reglas STANDARD y DAYLIGHT) proveniente de una biblioteca mantenida. Usar UTC para eventos puntuales con asistentes en muchas zonas, y hora flotante solo para lo que realmente sigue el reloj de pared de quien lee; los eventos de todo el día usan un valor DATE (DTSTART;VALUE=DATE:20260916) en lugar de una medianoche flotante.
• Para eventos recurrentes, seguir RFC 5545: cuando DTSTART tiene un TZID, la parte UNTIL de la regla debe estar en UTC. Modificar apariciones individuales con RECURRENCE-ID en lugar de editar la serie.
• Enviar las invitaciones como una parte text/calendar con el parámetro method establecido (method=REQUEST), y añadir el mismo objeto como adjunto .ics para los clientes que ignoran el parámetro.
• Realizar una prueba de ida y vuelta con al menos dos familias de clientes a través de un cambio de horario de verano, incluyendo una actualización y una cancelación.

Trampas

Usar un UID nuevo en cada actualización (duplicados). Nombres de zona que no son identificadores IANA, que otros clientes no pueden mapear. Cancelar con STATUS:CANCELLED pero sin METHOD:CANCEL. Eventos de todo el día enviados como UTC de medianoche a medianoche, que se desplazan un día en otras zonas. Enviar un CANCEL sin incrementar SEQUENCE, algo que RFC 5546 exige.