iCalendar (ICS)
Also known as: ICS file, .ics, CalDAV, iCal, webcal
ICS (iCalendar) is the file format and protocol standard that calendar apps use to share events.
When you receive a meeting invite that works in Outlook, Google Calendar, and Apple Calendar, it's formatted as iCalendar. The .ics file attachment contains event details -- start time, duration, location, attendees, and recurrence rules.
iCalendar (ICS), explained at three levels
At home
When you click 'Add to calendar' on an event website, you're usually downloading an .ics file. Your calendar app (Google Calendar, Outlook, Apple Calendar) opens it and adds the event -- because all these apps understand the iCalendar format.
At work
Meeting invitations work across different calendar systems (Outlook, Google Calendar, iCloud) because they all use iCalendar format under the hood. The invite email contains a MIME attachment in ICS format that the recipient's calendar app interprets.
At home
An .ics file is a plain-text file with structured properties: DTSTART/DTEND (event times), SUMMARY (title), DESCRIPTION, LOCATION, RRULE (recurrence -- 'every Monday for 12 weeks'), ATTENDEE (with RSVP status), ORGANIZER, and ALARM (reminder). Calendar subscription URLs (webcal://) provide live-updating ICS feeds for public calendars.
At work
CalDAV allows calendar clients to create, read, update, and delete events on a server using HTTP. Google Calendar, Apple Calendar, and Fastmail all expose CalDAV servers. This enables cross-platform sync -- an iOS Calendar app and a Linux desktop client can both sync to the same CalDAV server. Free/busy publishing allows scheduling apps to check availability without revealing event details.
At home
iCalendar's RRULE syntax handles complex recurrences: 'RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR;COUNT=10' means 'repeat on Monday, Wednesday, Friday for 10 occurrences'. EXDATE excludes specific occurrences (for holidays). VTIMEZONE components define timezone rules to handle daylight saving time changes correctly across time zones.
At work
iCalendar interoperability issues arise from implementation differences: not all clients handle RRULE edge cases identically, VTIMEZONE definitions may be incomplete, and meeting update handling (METHOD:REQUEST, METHOD:CANCEL) varies across email clients. Calendar scheduling extensions (iTIP/iMIP -- RFC 5546) define the invitation workflow: REQUEST sends invites, REPLY handles RSVPs, CANCEL cancels events.
Real-world examples
At home
Marcus subscribes to his city's public transit holiday schedule as a webcal:// URL in Google Calendar. The calendar updates automatically when the transit agency publishes changes -- no manual entry needed.
At work
Lena's team uses a CalDAV server to share a team project calendar. Each team member's calendar app syncs events bidirectionally -- anyone can add or modify project milestones, and changes appear on everyone's calendar within seconds.
Common confusions
- ICS files are calendar-app-specific and won't work across platforms — ICS is a universal open standard. An .ics file from an Apple Calendar event works in Google Calendar, Outlook, Thunderbird, and any other standards-compliant calendar app.
- Sharing an ICS file syncs the calendar in real time — An .ics file is a static snapshot. If the event changes, you'd need to send a new .ics file. Live sync requires CalDAV subscriptions or platform-specific calendar sharing.
For analysts
ICS files can be generated programmatically to invite stakeholders to meetings, export project milestones to personal calendars, or subscribe to data-driven schedules (earnings releases, regulatory deadlines) as calendar feeds.
History & origin
iCalendar was standardized as RFC 2445 in 1998 (updated to RFC 5545 in 2009) by the IETF. It extended the earlier vCalendar format from the 1990s. iCalendar became the universal calendar interchange format, supported by every major calendar application. The CalDAV protocol (RFC 4791) extended iCalendar for synchronized calendar subscriptions over the internet, enabling cross-platform calendar sync.