iCalendar

Every Calendar App Reads ICS. None Agree On What Happens Next. Why?

The iCalendar format is universal. Apple Calendar, Google Calendar, Microsoft Outlook, Mozilla Thunderbird, and every CalDAV server speak text/calendar natively. Drop a .ics file into any of them and it imports without conversion.

What is not settled is what the calendar app does next.

A VCALENDAR container holds one or more components: VEVENT for meetings, VTODO for tasks, VJOURNAL for journal entries, VFREEBUSY for availability lookups, VTIMEZONE for timezone definitions, and VALARM for reminders nested inside events. Every component is delimited by BEGIN:NAME and END:NAME markers. The required PRODID line — PRODID:-//Google Inc//Google Calendar 70.9054//EN — fingerprints the application that produced the file.

Take the same .ics file and import it into Google, Apple, and Outlook. The event arrives in all three. Reminders may arrive in two of them. Attendee status may be parsed in one. iTIP scheduling verbs (METHOD:REQUEST, METHOD:REPLY, METHOD:CANCEL per RFC 5546) are interpreted differently by each implementation. The format is universal; the behavior is local. This is the canonical iCalendar problem: every app reads ICS, none agree on edge cases. Simple events expose the gap. Recurring events widen it.

One Line Encodes a Year of Meetings. Why Is RRULE the Hardest Sentence in the Spec?

RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR;UNTIL=20271231T235959Z is one line. It also encodes a date set that calendar apps must compute correctly across decades, time zones, and exception lists.

The recurrence rule grammar gives you seven free parameters. FREQ chooses the base frequency (SECONDLY through YEARLY). INTERVAL multiplies the gap. COUNT or UNTIL bounds the series. BYDAY, BYMONTHDAY, BYMONTH, BYYEARDAY, BYWEEKNO, BYHOUR, BYMINUTE, BYSECOND, and BYSETPOS narrow the set. Combining them produces 'every other Tuesday in months with 31 days' or 'the last weekday of each quarter' — patterns that look reasonable in English and look like dense math in RRULE syntax.

EXDATE removes specific instances. RECURRENCE-ID overrides a single instance with a different DTSTART. RDATE adds one-off occurrences that don't match the main rule.

The combinatoric expansion is why ICS parsing libraries are not small. ical.js and python-icalendar each ship thousands of lines just to expand recurrence sets correctly, and corner cases — BYDAY=FR;BYMONTHDAY=13 for Friday-the-13th, daylight-saving boundaries inside an INTERVAL=3 monthly rule, leap-day annual events on February 29 — still produce calendar bug reports decades after RFC 5545. Once the date set is computed correctly, the time zone still has to resolve — and that is where spec mechanics collide with politics.

A 9 AM Beirut Meeting Landed at Two Different UTC Moments in 2023. How?

A meeting at 9 AM in Beirut on 26 March 2023 happened at two different UTC instants depending on which faction of the Lebanese government you trusted.

ICS gives an event three ways to express a time. Add a Z suffix — DTSTART:20260415T060000Z — and the time is unambiguous UTC. Reference a TZID — DTSTART;TZID=Europe/Paris:20260415T090000 — and the time is local to that named timezone, which the parser must look up either in an embedded VTIMEZONE block or in the Olson database. Skip both and you have a 'floating time' — interpreted in whatever local timezone the viewer happens to be in.

Most cross-region scheduling complications are timezone definition disputes, not ICS spec failures. Countries that don't observe DST — Japan (UTC+09:00), India (UTC+05:30), most of Africa — are the easy case. Egypt reintroduced DST on 28 April 2023 after a decade of suspension — every Egypt-tagged ICS event from before that date may now decode wrong if the parser used a stale Olson database. Lebanon's March 2023 chaos was worse: the prime minister postponed DST to keep mornings shorter during Ramadan, Christian leaders rejected the decision, and for ~4 days Lebanon ran in two simultaneous time zones — 'Christian Time' (UTC+03:00) and 'Muslim Time' (UTC+02:00). Aviation systems, telecoms, and hospital scheduling all broke. iCalendar's flexibility — three valid ways to write a time — became the problem. Time zones are a tooling problem. Which days count as which is the deeper one.

RFC 7529 Added Non-Gregorian Recurrence in 2015. Why Does Every App Still Ignore It?

Chinese New Year moves every year by lunar calculation. Passover shifts through March and April by the Hebrew calendar. Diwali lands on a different Gregorian date each fall. Ramadan rotates backward eleven days annually through the Hijri calendar. None of these can be expressed as a simple RRULE.

ICS hardcodes the Gregorian calendar in DTSTART. RFC 7529 (2015) added the RSCALE parameter so recurring events could reference non-Gregorian calendars — Hebrew, Chinese, Islamic-Civil, Ethiopic, Indian. Ten years later, most calendar apps still ignore the parameter. Apple Calendar has basic RSCALE support. Google Calendar lacks server-side handling. Outlook, Thunderbird, and most CalDAV servers drop RSCALE silently on import.

The practical consequence: a Jewish community calendar needs a manually-maintained annual EXDATE list for Passover. A Chinese business calendar maintains two parallel subscription feeds — one for Western holidays, one for lunar ones computed offline. An Islamic prayer-time calendar publishes as a static yearly .ics file rather than a recurring rule, because no cross-app recurring rule can express 'five prayers whose times shift with sunrise' reliably.

Every non-Gregorian recurrence across every culture still comes down to Gregorian DTSTART plus externally-computed display at render time. Twenty-six years of iCalendar evolution, ten years after the spec added the fix, and the ecosystem still does not support it. The format met the technical challenge. The implementations never caught up.