A Recurring Event Is One Line in the CSV, Not Twelve

What a calendar file actually contains

Open an .ics in a text editor and it is a list of blocks, each one BEGIN:VEVENT to END:VEVENT, holding a start, an end, a title and a handful of other properties. A repeating appointment is one such block plus a single line, RRULE, that says how it repeats. Twelve weekly points are twelve lines on screen and one block on disk, and the twelve dates are computed by whatever is displaying them.

That design is why a calendar can hold a birthday that repeats for ever in a few dozen bytes, and why moving one occurrence of a series is a whole separate property, RECURRENCE-ID, rather than an edit to a row. It is also why a converter cannot invent the occurrences without becoming a calendar engine of its own — with the leap years, the daylight-saving jumps and the exception dates that go with it.

The eight columns, and what falls outside them

The export writes summary, start, end, location, description, organizer, status and uid — in that order, one row per VEVENT. A spreadsheet is a rectangle, and everything an event carries that is not one value per event has nowhere to go: the recurrence rule, the alarms, the attendee list, the attachments, the time zone the start was written in. Keep the .ics itself if any of those matter; the CSV is for reading, sorting and counting, not for archiving.

Getting one row per occurrence, when you really need it

Ask the calendar to do the expanding, because it is the only thing that knows your exception dates. In Google Calendar, Outlook and Apple Calendar the reliable route is the same: switch to a list or agenda view over the period you care about, select the range, and export or print that — a view is already expanded, so what leaves it is one line per occurrence. Exporting the calendar itself gives you the compact form again, rule included.

The other direction is worth knowing too: if you build an .ics from a spreadsheet where you have already written out every date, you get exactly the events you listed, with no rule attached. That is usually what you want for a schedule of one-off sessions, and it is a poor way to store a standing weekly meeting, which will then be twelve separate items to move if the time changes.

Frequently asked questions

My CSV has fewer rows than my calendar shows. Is the converter broken?

Almost certainly not — count your repeating events. Each one is a single VEVENT in the file however many times it shows on screen, so a calendar displaying 60 appointments can easily be a file holding 12. Open the .ics in the viewer and compare its event count with the CSV's row count: if they match, nothing was lost in the conversion.

Can I edit the CSV and turn it back into a calendar?

Yes, and that round trip is the point of having both tools — but it comes back as one-off events. A series exported as a single row and re-imported is a single appointment: the rule was never in the spreadsheet. Edit titles, times and locations there freely; rebuild recurrences in the calendar afterwards.

Which tool keeps the recurrence rule?

The .ics viewer and the JSON export both show it, and merging .ics files keeps it, because all three stay inside iCalendar. Only the CSV drops it, and only because a spreadsheet column cannot hold it. If your job is to inspect or move calendars rather than to count them, prefer those three and leave the CSV for the times you actually want a table.

Is my calendar uploaded anywhere?

No. The file is read in your browser and the CSV is built there; nothing leaves the machine. That matters more for a calendar than for most files, because an agenda is a map of who you meet and where you are — the kind of thing worth converting without handing it to a server.