Building a Calendar From a Schedule You Already Have in a Spreadsheet
Published 9/10/2026 · 4 min read · File tools
Daniel Okonkwo — Front-end developer and tech writer at OneKitly
Web performance · File formats
Checked against 3 sources
The importer needs a header row and at least one of four columns: a title, a start, an end and a location — in English or in any of French, Spanish, Portuguese, German or Italian, so titre, début, fin, lieu works as well as summary, start, end, location. Write the dates the unambiguous way, year first: 2026-09-07 for a whole day, 2026-09-07T14:00:00Z for a moment. Everything else is optional, and columns the tool does not recognise are ignored rather than guessed at, so the reference numbers and the room capacities in your sheet cost nothing. What comes out is a list of separate events, one per row, with no recurrence rules attached — which is exactly right for a programme of one-off sessions and the wrong way to store a standing weekly meeting. Load the result in the .ics viewer and check one row before importing a hundred; a date that a spreadsheet quietly reformatted is the failure you are looking for.
Course timetables, match fixtures, shift rotas and conference programmes all start life as a table. Four columns are enough to turn one into a file every calendar application can import.
One row, one event — and why that is usually what you want
A term's teaching, a season's fixtures and a festival's programme are all lists of individual occasions that happen to fall into a pattern. Written out as rows they can be edited one at a time, which is what actually happens: one lecture moves to a different room, one match is postponed, one talk is cancelled. A recurrence rule would compress them and then fight you every time reality diverged from the pattern, which it does within the first fortnight.
The date column is where this goes wrong
Every other column is text and survives untouched. Dates are the one thing a spreadsheet believes it understands, so it reformats them to the convention of whoever opened the file — and 07/09/2026 is the seventh of September in most of the world and the ninth of July in the United States. The file will convert cleanly either way; it is the meaning that changed. Writing year-month-day removes the ambiguity at the source and is also what sorts correctly as text, which is a second reason to prefer it.
Frequently asked questions
- Can I give the events a time zone?
- Write the instant in UTC with a trailing Z — 2026-09-07T12:00:00Z — and every calendar will show it at the right local hour for whoever is looking. A CSV has no column for a named zone, so that is the way to be unambiguous from a spreadsheet. If the wall-clock time is what must stay fixed across a daylight-saving change, build the file and then edit the DTSTART lines, or keep the calendar in .ics from the start.
- What if I leave the end column empty?
- The event is written with a start and no end, which most calendars display as a short block of their own default length. It is fine for a deadline or a reminder and unhelpful for a lecture. If your sheet has a duration rather than an end time, add an end column and compute it once with a formula — a spreadsheet does that better than any converter could.
- Can other people subscribe to the file I made?
- Only if you publish it somewhere with a stable address, because subscribing means fetching a URL periodically. A file you email is imported once and then diverges from your sheet the moment you edit a row. For a schedule that will change, publish the .ics at a fixed address and rebuild it there when the sheet changes — the subscribers then follow along without another import.
Articles you may find interesting
All guides →Related tools
Sources
Spotted a mistake in this article?