Google Calendar CSV import: getting a long list of dates in at once

A spreadsheet holds sixty dates. A term timetable, a delivery schedule, a season of fixtures, a list of shifts that arrived as an attachment. Typing them into Google Calendar one at a time is an afternoon of work, and the import screen offers to finish it in one click. It does finish it, under conditions worth knowing before the file is built, because the import is quiet about most of what it leaves behind.

The mechanics are small enough to hold in your head. There are two required columns, seven optional ones, one destination calendar, and a short list of things that never make the trip. Once that list is clear, the decision is not how to format a CSV file but whether a CSV file is the right shape for the job at all.

Where the import lives and what it accepts

The importer sits in the settings screen, not on the grid. Open Google Calendar in a browser, click the settings icon at the top right, then Import & export in the left menu. Pick the file, pick the calendar the events should land in, and click Import. Events go to the primary calendar unless another one is chosen.

Two constraints on that screen catch people out. The first is the platform. Google's documentation states that importing works with ICS and CSV files on a computer, and the phone and tablet apps have no equivalent screen. A file sitting in a phone's downloads folder has to reach a desktop browser first.

The second is the shape of what gets uploaded. A file exported from another calendar often arrives as a .zip archive containing one .ics file per calendar. The importer does not open archives. The archive has to be unpacked and each .ics file imported separately, which also means the destination calendar is chosen separately for each one.

One more thing worth fixing in mind before starting: an import is a copy, not a link. Google's help page is explicit that imported events do not stay in sync between two accounts, and points to calendar sharing as the route for anything that needs to keep matching. Importing the same file twice produces two sets of events, not one updated set.

Two required columns and seven optional ones

The CSV format Google reads is a flat table with a header row. The header names have to be in English regardless of the language the account is set to, and only the first two are required.

Column header	Required	Example
Subject	Yes	Final exam
Start Date	Yes	05/30/2020
Start Time	No	10:00 AM
End Date	No	05/30/2020
End Time	No	1:00 PM
All Day Event	No	False
Description	No	"50 multiple choice questions"
Location	No	"Columbia, Schermerhorn 614"
Private	No	True

The examples above are the ones Google publishes. The date format in them is month, day, then four-digit year, and the times use a twelve-hour clock with AM or PM. Any value that contains a comma has to be wrapped in quotation marks, otherwise the spreadsheet splits it into two columns and the row collapses. All Day Event and Private both take True or False rather than a checkbox or a yes.

That is the whole vocabulary. A spreadsheet editor such as Google Sheets or Numbers will happily save a file with more columns in it, and the extra columns are ignored rather than flagged.

What the file cannot carry

The header list is the honest limit of the format, and reading it as a list of absences is more useful than reading it as a list of features. There is no column for guests. No column for a time zone. No column for a repeat rule. No column for a reminder or an alert. No column for a video meeting link.

Two of those are stated outright in the documentation rather than implied.

When you import an event, guests and conference data for that event are not imported.

That is from Google's own import instructions, and it applies to ICS files as much as to CSV ones. An event that was a meeting with eight people becomes a block of time with a title.

The second is the one that turns a tidy file into a maintenance problem.

If you import repeat events from a .csv file, they might not show up that way. They'll be on your calendar as a series of one-time events.

A weekly class that runs for forty weeks therefore needs forty rows, and once it is on the calendar it is forty independent events. Moving the class to a different hour means editing forty events, because there is no series holding them together. The same goes for a monthly review or a fortnightly standup. For anything that genuinely repeats, the repeat should be created once in Google Calendar and left as a series, and the CSV reserved for the dates that do not follow a rule.

The missing time zone column matters in the same quiet way. The times in the file are read against the calendar's own time zone, so a file built by someone in one country and imported by someone in another produces a grid that looks right to whoever made the file and wrong to whoever imported it.

CSV or ICS, put side by side

Both formats go through the same screen, so the choice is about what the file needs to survive.

What the file has to hold	CSV	ICS
Title, date, time, place	Yes	Yes
A repeat rule kept as one series	No, arrives as separate events	Yes, as an RRULE line
A time zone per event	No column exists	Yes
Guests	Not imported	Not imported
Built and edited in a spreadsheet	Yes	No, it is a text file
Required structure	English header row	BEGIN:VCALENDAR to END:VCALENDAR

An ICS file is plain text with a fixed skeleton. Google's guidance is that the first line must be BEGIN:VCALENDAR, that header lines such as VERSION:2.0 and a PRODID line follow it, that every event sits between BEGIN:VEVENT and END:VEVENT, and that the last line is END:VCALENDAR. The format itself is the iCalendar standard defined in RFC 5545.

The practical trick Google suggests for anyone hand-building one is to export an existing calendar as .ics first and use that file as the template, which removes the guesswork about the header block entirely.

One detail on Google's own export advice is worth reading twice. The page tells anyone exporting from another application to choose CSV where the format can be chosen, and to choose vCard on an Apple device. vCard is the format for contacts rather than calendars, and Apple's Calendar app on the Mac does not offer it: the documented route there is File then Export then Export, which writes an .ics file, with File then Export then Calendar Archive writing an .icbu file that the Google importer will not read. So on a Mac the practical answer is the .ics file, and the archive format is only useful for restoring back into Apple Calendar.

So the rule of thumb is short. A flat list of one-off dates with no attendees is a job for CSV, because a spreadsheet is a far better editor than a text file. Anything with repeats or mixed time zones is a job for ICS, and if that means spending twenty minutes learning the shape of a VEVENT block, it still costs less than maintaining four hundred loose events later.

Where imports go wrong

Almost every failed import traces back to one of a handful of causes, and the error message on screen rarely names which.

Header names in the wrong language is the most common single cause. A spreadsheet started in a Japanese or German interface, or exported from a tool that localises its column names, produces headers the importer does not recognise even though the data underneath is perfect. The fix is to retype the header row in English.

Date formatting is the next one. Spreadsheet editors reformat date cells according to the locale of the document, so a column that was typed as 05/30/2020 can be saved as 2020-05-30 or 30.05.2020 without anyone touching it. Setting the column to plain text before typing keeps it stable.

Then there are the small structural faults. A comma inside a location or a description that was not quoted. Blank rows at the bottom of the sheet that the editor still exports. A file saved in the editor's native format with the extension changed by hand rather than exported as CSV. An All Day Event column filled with Yes instead of True.

One habit removes most of the risk from all of this. Create an empty calendar, import into that, and look at the result before moving anything. A botched import into a new calendar is deleted by deleting the calendar. A botched import into a primary calendar has to be unpicked event by event, and there is no undo for an import.

When the spreadsheet is the wrong starting point

The CSV route assumes the dates already exist in a table. Often they do not. They are in an email, in a PDF timetable, in a message thread, in a photograph of a whiteboard. Building a CSV file from that material means typing everything twice, once into the spreadsheet and once, effectively, into the calendar.

A desktop calendar on the Mac changes the arithmetic here, because the entry step is where the time goes rather than the import step. Writing a line of ordinary text and having the date, the place, the guests and the repeat read out of it turns a pasted block of email into a draft event, which is faster than a spreadsheet for anything under a few dozen items. The mechanics of that are in the Entering events section of the guide, and the wider set of entry routes is listed under Features.

The other half of the job is what happens after the dates land. A list of appointments imported from a client's schedule looks fine on the grid and still fails in practice if two of them are an hour apart at opposite ends of a city. Calculating the trip between consecutive events and putting a travel block in front of each one is covered under Travel time, and it is the step that turns an imported list into a workable day.

What to change first

Decide whether the list repeats. If it does, build the repeat once as a series in Google Calendar and import only the exceptions, because a CSV file cannot carry a repeat rule and will hand back one loose event per date. If it does not repeat, import into a fresh empty calendar first so a bad run costs one click to undo.

For anything that arrives as text rather than as a table, skip the file entirely and let the entry panel read the line. Caltimate does that on the Mac, and it is the shorter path for every list small enough to read in one sitting.