ICS to CSV Converter

The iCalendar format, standardised as RFC 5545, describes a calendar rather than tabulating one. A file opens with BEGIN:VCALENDAR and closes with END:VCALENDAR, and between those markers sit component blocks — VEVENT for an appointment, VTODO for a task, VTIMEZONE to define what a named zone meant at a given date, VALARM nested inside an event for its reminder. Each line is a property name, optional parameters after a semicolon, then a colon and the value: DTSTART;TZID=America/New_York:20260614T090000 is one property carrying one timestamp and the zone it should be read in.

Two details of that encoding defeat naive attempts to read an ICS file in a spreadsheet. The first is line folding: RFC 5545 caps lines at 75 octets and continues longer values on the next line, marked by a leading space. A meeting description of any length is therefore shattered across several physical lines that must be rejoined before the value means anything. The second is escaping — newlines inside a description are written as a literal backslash-n, and commas are backslash-escaped, both of which have to be undone rather than passed through into a comma-delimited file. This converter reassembles folded lines and unescapes those sequences before writing anything out.

What comes back is one row per event with six columns, which is the shape people actually want calendar data in. Consultants total billable hours by subtracting DTSTART from DTEND and grouping on a client name in the title. Managers pivot a quarter of meetings to see where the week goes. Teams hand a schedule to someone who does not use their calendar system, or push events into a CRM or project tracker that imports CSV and nothing else. In each case the calendar is a source of records, and CSV is the only format every downstream tool agrees to read.

A weekly meeting shows up only once. That is how iCalendar stores it. The repetition lives in an RRULE property on a single VEVENT, not in fifty-two copies of the event, so there is one row to export. Occurrences that were individually moved or cancelled are exceptions and do appear separately — which is why a recurring series sometimes yields two or three rows rather than one.

An all-day event ends a day later than it should. RFC 5545 defines the end of an all-day event as exclusive, so a one-day event on the 14th genuinely records DTEND as the 15th. The value in the file is correct; it just means "up to but not including". Duration arithmetic works out right, so only read DTEND in isolation with that in mind.

Times are off by several hours. Timestamps are exported exactly as the file writes them, with no timezone conversion applied. Google exports frequently store times in UTC with a trailing Z, which reads as a five-hour shift on the US east coast and eight on the west. Add the offset in a spreadsheet column rather than assuming the export is wrong.

The DESCRIPTION column is empty for every event. Some exports deliberately omit event bodies. Outlook's export dialog offers availability-only and limited-detail levels that strip descriptions, and calendars shared with limited visibility often expose only the title and times. Re-export with full details selected if the bodies matter.