Duplicate a calendar in Google Calendar before you rearrange it

The reason to duplicate a calendar is almost always the same. Something big is about to change, a whole quarter of recurring meetings is going to be rearranged, or a working calendar is about to be handed to someone else, and a copy of the current state would be worth having before any of that starts.

Google Calendar has no command for it. What exists instead is a route built out of two other features, and that route behaves in ways that surprise people the first time. The copy can silently land on top of the original rather than beside it, and several kinds of event do not survive the trip at all. Both of those are predictable once the mechanism is clear.

There is no duplicate command, at any level

This is worth establishing before hunting for a hidden menu. Google Calendar's own API, which is the full set of operations the product supports, offers exactly these actions on a calendar: create one, read one, change its properties, delete it, clear all events out of it, and transfer its ownership. There is no copy and no duplicate. The web interface offers no more than the API does.

For individual events the picture is slightly better but still not a copy operation. Events can be created, read, changed, deleted, duplicated one at a time in the interface, imported, and moved. Moving is the one most often mistaken for copying, and Google describes it plainly: moving an event to another calendar changes the event's organizer. The event leaves the source calendar. Nothing is duplicated.

So the only route to a second copy of a whole calendar is to write the contents out to a file and read them back into a new calendar. Every tool, extension, and automation service that advertises calendar duplication is doing some version of that, whether or not it says so.

The export and import route

The mechanics are short. In Google Calendar settings there is an Import and export section. Export produces a zip archive containing one iCalendar file for each calendar in the account, which means a single export is a snapshot of everything rather than of the one calendar in question.

Then create the destination. A new calendar has to exist before anything can be imported into it, because import asks which calendar to put events in and offers no way to create one on the spot.

Then unzip the archive, find the file matching the calendar to be copied, and import that one file into the new calendar. Import handles one file at a time and puts everything in it into a single destination calendar, so a calendar split across two files has to be imported twice.

Two limits in this route are worth knowing before starting. The first is that exported files cover events, not the calendar's own settings: the name, the colour, the sharing rules, and the default reminders are properties of the calendar rather than of its events. A freshly created destination calendar starts with defaults for all of them, and matching the original means setting them by hand. The second is that per person reminder settings never travel at all. Google's documentation describes default reminders as private information specific to the authenticated user, held in user specific calendar metadata rather than in the shared calendar record. A duplicated team calendar therefore arrives with nobody's reminders configured.

The identifier that decides whether the copy is separate

This is the part that catches people, and it is worth understanding rather than working around blindly.

Every event in an iCalendar file carries a UID. The standard defines it as the persistent, globally unique identifier for that event, and requires that whatever generated it guarantees uniqueness. It exists so that a later message about the same event can be matched to it:

This property is an important method for group-scheduling applications to match requests with later replies, modifications, or deletion requests. Source: rfc-editor.org

Google's API reflects the same rule from the other direction. The import operation requires this identifier to be supplied, describing it as the value that uniquely identifies events across calendaring systems. It also notes that in a recurring event, every occurrence has a different internal id while all of them share one UID.

The consequence for duplication is direct. An exported file carries the original UIDs. Importing that file back into the same account hands the calendaring system a set of events it already knows by identity. Whether the result is a second copy or an update to the events already there is decided by that matching, not by the choice of destination calendar. This is the mechanism behind the common report that importing an exported calendar produced no visible new events, or produced events that changed the originals.

Anyone who needs a copy that is genuinely independent has to rewrite the UID of every event in the file before importing it. That is a text substitution on the exported file rather than anything Google Calendar offers, and it is the step that separates a working duplicate from a confusing one.

The four routes, compared

Route	Original stays	Copy is independent	Practical ceiling
Export, then import into a new calendar	Yes	Only if UIDs are rewritten first	Whole calendar, one file at a time
Duplicate events one at a time in the interface	Yes	Yes	A handful of events
Move an event to another calendar	No, it leaves	Not a copy at all	Reorganising, not copying
Share the calendar instead of copying it	Yes	No, it is the same calendar	When the goal was access, not a snapshot

The last row deserves attention because it is the right answer more often than people expect. A request to copy a calendar for a colleague is usually a request for that colleague to see it, and sharing achieves that without creating a second set of events that will immediately start drifting out of step with the first.

What does not come across

Several categories of event either change or vanish on the way through, and Google documents each.

Non standard event types. Only ordinary events can be imported. Google states that birthday, focus time, events from Gmail, out of office, and working location events cannot be moved between calendars, and that importing a non default event changes its type to ordinary and drops the properties specific to that type. A calendar full of focus time blocks does not duplicate as focus time blocks.

Meeting links. Conference details are only carried when the tool doing the import explicitly asks for them, and the default is to ignore them. Google attaches a warning to this area that matters beyond the mechanics: reusing the same conference details across different events can cause access problems and expose meeting details to people who were not meant to see them. A duplicated calendar that carried its video links across would be a privacy problem rather than a convenience.

Attachments. Support for event attachments is off by default in the same way, so a copy made by a tool that does not ask for it arrives without them.

Guest responses. Google warns that importing an event with attendee responses already marked as accepted, tentative, or declined can cause those responses to be reset for guests whose settings only add invitations after they respond by email. It also notes that response status is not propagated when more than 200 guests are invited. A duplicated calendar is not a reliable record of who had agreed to what.

Taken together, these mean a duplicate is a good snapshot of times, titles, and descriptions, and a poor snapshot of the social state of the calendar. That distinction is worth making explicit before handing a copy to anyone as a record.

Where the import step actually fails

Google publishes the error messages this route produces, and each one points at a different cause.

"Processed zero events" appears when the Import button was clicked more than once. The first click succeeded and the second had nothing left to do, so the response is to go and look at the destination calendar rather than to import again. The same message also appears when the formatting of the file is wrong.

"Processed x of y events" means some entries in the file could not be read. The documented advice is to export again from the source application and reimport, because a partial read is usually a formatting problem in the file rather than a limit being reached.

"Google Calendar is temporarily unavailable" is the misleading one, because it reads like an outage. It appears when the file is too large. Google states the limit plainly: keep files to one megabyte or smaller. A calendar holding several years of history exports well past that, and the documented fix is to export shorter date ranges, or to split the file into smaller pieces by hand. That single limit is the reason duplicating a long lived calendar is a sequence of imports rather than one.

"The connection to the server was reset" is the fourth documented message, and it points back at formatting as well. For a comma separated file, the delimiter has to be a comma rather than a semicolon or a colon, which is the difference a spreadsheet exported under a European locale tends to produce.

Two more problems show up after an import has reported success. Events landing at the wrong time means the time zone set in Google Calendar and the one set in the source application do not agree, and correcting both before reimporting is the fix. Recurring events arriving as a run of separate one off entries means the source application wrote them out that way, and the same outcome is documented for repeat events imported from a comma separated file. A calendar duplicated like that has lost the ability to edit a whole series in one action, which is usually the reason the series existed.

When a copy is the wrong tool

Three situations come up repeatedly where the copy is not what was actually needed.

Handing a calendar to a successor is a transfer of ownership rather than a copy, and Google Calendar supports that directly for a secondary calendar. Transferring keeps one calendar with one set of events, which is what everyone involved wants a month later.

Keeping a record before a reorganisation is an export, not a duplicate. The exported file sitting in a folder is the snapshot. Importing it into a live calendar adds a second set of events that someone will have to clean up, and the cleanup is the part that goes wrong.

Trying out a different arrangement of the week is better done in a new empty calendar than in a copy of the old one. Copying brings across every decision that was already made, including the ones the rearrangement is meant to undo. Deciding which events actually need a place first, and where the travel between them goes, is covered in travel time.

What to change first

Export before touching anything, and keep the file. If the copy is meant to live alongside the original, rewrite the UIDs in the exported file before importing, otherwise the import will negotiate with the events already there. If the real goal was for someone else to see the calendar, share or transfer it instead, and skip the copy entirely. For a working calendar that stays readable while it is being rearranged, a desktop calendar that shows travel and gaps as part of the day is doing more useful work than a second copy, which is what Caltimate is built around.