iCalendar invites: UID, SEQUENCE and getting time zones right

What it is

iCalendar (RFC 5545, media type text/calendar) describes events as VEVENT components inside a VCALENDAR. iTIP (RFC 5546) defines how they are exchanged: METHOD:REQUEST from the organiser, METHOD:REPLY from attendees with a PARTSTAT (accepted, declined, tentative), METHOD:CANCEL to withdraw. An event is identified across all messages by UID; a revision by SEQUENCE, which the organiser must increment when it changes DTSTART, DTEND, DURATION, RRULE and similar properties. Times come in three forms: UTC (20260916T090000Z), local time with a TZID parameter that refers to a VTIMEZONE component in the same object (DTSTART;TZID=Europe/Zurich:20260916T110000), and floating time with neither, meaning "11:00 wherever the reader is". RFC 5545 requires a VTIMEZONE for every TZID used and warns that omitting it leads to inconsistent interpretation of local time.

Why it matters

An invite that lands an hour off after a daylight-saving change, or that creates a duplicate on every update, is worse than none. Calendars are one of the places where "store UTC" is not enough: a weekly 09:00 meeting in Zurich must stay at 09:00 local time across the March and October transitions, which only a zone-anchored local time expresses.

How to apply

• Generate a stable UID per event, store it, reuse it in every update and cancellation, and increment SEQUENCE on each substantive change; DTSTAMP is the message time, not the revision counter.
• Use TZID with IANA zone names and embed a correct VTIMEZONE (with STANDARD and DAYLIGHT rules) from a maintained library. Use UTC for one-off events with attendees in many zones, and floating time only for things that genuinely follow the reader's wall clock; all-day events use a DATE value (DTSTART;VALUE=DATE:20260916) rather than a floating midnight.
• For recurring events, follow RFC 5545: when DTSTART has a TZID, the UNTIL part of the rule must be in UTC. Modify single occurrences with RECURRENCE-ID instead of editing the series.
• Send invites as a text/calendar part with the method parameter set (method=REQUEST), and add the same object as an .ics attachment for clients that ignore the parameter.
• Round-trip test with at least two client families across a DST boundary, including an update and a cancellation.

Pitfalls

A new UID on every update (duplicates). Zone names that are not IANA identifiers, which other clients cannot map. Cancelling with STATUS:CANCELLED but no METHOD:CANCEL. All-day events sent as midnight-to-midnight UTC, which shift by a day in other zones. Sending a CANCEL without incrementing SEQUENCE, which RFC 5546 requires.