Event import and export: what it does and where it breaks down

Every calendar app has an Import and an Export option somewhere in its settings, and most people touch them only once or twice: when leaving a job, when switching apps, or when a school sends out a term schedule as an attachment. Because the feature is used so rarely, it is easy to assume it does more than it does, and then be surprised when events arrive without attendees, at the wrong hour, or twice.

Export writes calendar events into a file. Import reads that file into another calendar. That is the entire mechanism, and nearly every surprise traces back to what the file can and cannot carry. The clearest way to understand the feature is to look at the file itself.

What import and export are for

A file transfer is a one time copy. It suits situations where a calendar is changing hands or changing homes:

• Moving history out of an account that is about to close
• Switching from one calendar app or service to another
• Keeping an offline copy of past events
• Bringing a published schedule, such as a term calendar or event programme, into a personal calendar

What these have in common is that they happen at a moment, not continuously. The file reflects the calendar at the instant it was written. Microsoft's Outlook.com documentation describes an imported file as a snapshot of the events at the time of import, and adds that imported events are not refreshed when the calendar's owner makes an update. A file import into Google Calendar or Apple Calendar behaves the same way for a simple reason: the file carries no link back to the calendar it came from.

The timing question is more pressing than usual in 2026. Microsoft has announced that support for legacy Outlook for Mac ends in October 2026 and that Exchange Web Services in Exchange Online will be retired on October 1, 2026. People moving off the legacy client, or using the change as a reason to consolidate calendars, are likely to meet these menus again.

Inside an .ics file

Almost every calendar exchange uses the iCalendar format, defined in RFC 5545, published in September 2009. The standard specifies the extension directly:

The file extension of "ics" is to be used to designate a file containing (an arbitrary set of) calendaring and scheduling information consistent with this MIME content type. Source: rfc-editor.org

An .ics file is plain text. A single weekly meeting looks roughly like this:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp//Example Calendar//EN
BEGIN:VEVENT
UID:[email protected]
DTSTAMP:20260914T000000Z
DTSTART;TZID=Asia/Tokyo:20260915T100000
DTEND;TZID=Asia/Tokyo:20260915T110000
RRULE:FREQ=WEEKLY;BYDAY=TU
SUMMARY:Weekly planning
LOCATION:Room 4
DESCRIPTION:Agenda in the shared folder
END:VEVENT
END:VCALENDAR

Each line has a job, and each job corresponds to a way the transfer can go wrong.

The wrapper

BEGIN:VCALENDAR and END:VCALENDAR mark the start and end of the file. PRODID names the software that wrote it. Google's troubleshooting page for imports points to incorrectly formatted headers and footers as a cause of failure, which is usually this wrapper being damaged or missing after a file has been edited by hand or generated by a custom tool.

The identity

UID is the event's permanent identifier. RFC 5545 is unambiguous that the UID itself must be a globally unique identifier, and that whatever generates it must guarantee that uniqueness. Calendar software relies on this value to recognise an event as the same event. A file that has been opened and resaved by a program that regenerates identifiers can end up describing familiar events under new identities.

The time

DTSTART and DTEND carry the start and end, and the TZID parameter says which time zone those numbers belong to. A value ending in Z, like the DTSTAMP line, is in UTC. When the time zone information and the receiving calendar's settings disagree, events shift by whole hours. Google's help describes exactly this: events show at the wrong time when the time zone in Google Calendar does not match the application that created the file.

The repetition

RRULE expresses a repeating pattern in one line. This is what keeps a weekly meeting a single series rather than fifty separate events. Some exports flatten the rule into individual occurrences, and spreadsheet formats have no equivalent at all, which is why Google warns that repeating events imported from a .csv file may appear as one time events.

The text

SUMMARY, LOCATION and DESCRIPTION hold the visible details. RFC 5545 also states that lines should not be longer than 75 octets, so long descriptions are folded onto continuation lines. Hand editing that ignores the folding is a quiet way to break a file.

Notice what is not in the example: no attendees, no video meeting link, no color. Those can exist in iCalendar or in an app's own data, but whether they survive depends on the apps at both ends.

Reading a file before importing it

Because an .ics file is text, a few minutes of reading it in a plain text editor can predict how an import will go. Open it without saving, so nothing is changed by accident, and look for five things.

First, count the events. Each event starts with a BEGIN:VEVENT line, so a search for that phrase gives the total. That number is the one to compare against the destination afterwards. If Google Calendar reports that it processed fewer events than the file contains, the gap is the set of events it could not read.

Second, look at the size. Google Calendar's limit is 1MB. A file close to or above that should be split by date range at the source before anything is attempted, because an oversized file is one of the documented causes of a failed import.

Third, check how times are written. Lines with a TZID parameter carry a named time zone. Lines ending in Z are in UTC. Lines with neither are floating times that the receiving app will interpret in its own zone. A file that mixes these, or names a zone the destination does not expect, is a candidate for shifted events.

Fourth, check whether RRULE lines exist. If a calendar full of weekly meetings produces a file with no RRULE lines at all, the source app has written each occurrence as its own event, and the destination will receive them that way. Fixing that means changing the export, not the import.

Fifth, glance at the first and last lines. A healthy file starts with BEGIN:VCALENDAR and ends with END:VCALENDAR. A file that starts with something else, such as a web page's markup saved by mistake, is not a calendar file, whatever its extension says.

None of this requires technical skill beyond using a search box, and it turns a trial and error import into a predictable one.

The file types that show up in practice

Not every export is an .ics file, and the type decides where the file can go next.

File	Produced by	What it contains	Where it can go
.ics	Google Calendar, Apple Calendar, Outlook and others	Events in iCalendar format	Any major calendar app
.zip	Google Calendar when exporting all calendars	One .ics per calendar	Unzip first, then import each .ics
.csv	Spreadsheets and some apps	One event per row	Google Calendar, with its English column headers
.icbu	Apple Calendar's Calendar Archive	Every calendar on the Mac	Back into Apple Calendar; Outlook for Mac cannot import it
.olm	Outlook for Mac	Mail, contacts, calendar and other items	Outlook for Mac
.pst	Outlook for Windows	Mail, contacts, calendar and other items	Outlook for Windows, and import into legacy Outlook for Mac

Two rows cause most of the trouble. The .icbu archive is a restore file, and Apple warns that importing a calendar archive replaces all current calendar information and data. The .csv format is convenient to inspect but loses recurrence, and Google requires a comma separator and specific headers, with only Subject and Start Date mandatory.

What survives the move

The event itself generally arrives intact: title, start, end, location, description and, in .ics, the repeat rule. The losses are specific to each app and are documented.

Detail	Google Calendar import	Apple Calendar import	Outlook
Guests	Not imported	Not covered in Apple's import guide	Not covered in the pages reviewed here
Conference or meeting data	Not imported	Not covered in Apple's import guide	Not covered in the pages reviewed here
Custom colors	Not covered in Google's guide	Removed on import of .ics; all calendar colors removed on archive import	Not covered in the pages reviewed here
Later changes at the source	Not reflected	Not reflected	Not reflected for imports; subscriptions update on a delay

Where a cell says not covered, the vendor's documentation does not state an answer, and the safe assumption is to check with a small test import rather than rely on it.

Import compared with the alternatives

The real question behind most searches for this feature is not how to import but whether importing is the right tool. The deciding factor is who owns the event after the operation.

With an import, the destination owns a copy. It can be edited freely, and it will never hear about changes to the original. With a subscription to a published link, the source keeps ownership and the destination receives updates on a schedule; Microsoft states that Outlook.com refreshes subscribed calendars approximately every 3 hours, that Outlook on the web does so every 6 hours, and that an update can take more than 24 hours. With sharing inside the same service, both sides see the same event, and changes appear for everyone. With several accounts added to one app, nothing moves at all; each account keeps its own events and the app simply shows them together.

Google adds a practical limit on the subscription route: adding a calendar by URL has to be done from a computer browser, not from the Android, iPhone or iPad apps.

Where it breaks down

Reading the file from top to bottom gives a checklist of failure points that works for any app.

Before the file exists, permission and platform matter. Google Calendar exports only from a computer, needs "Make changes and manage sharing" access to the calendar, and can be restricted by an administrator on work or school accounts.

At the file, size and packaging matter. Google Calendar accepts files of 1MB or smaller, and an all calendars export has to be unzipped before its .ics files can be imported one at a time.

At the destination, version matters. Microsoft's article on importing into legacy Outlook for Mac notes that Outlook on the web, iCloud and Google calendars cannot be imported at this time, while the new Outlook for Mac lists opening, exporting and saving .ics attachments as available.

After import, the file's own fields explain the symptoms. Shifted times point to TZID and time zone settings. A series that became separate events points to RRULE being flattened or a .csv source. Doubled events point to the same file being imported twice into the same calendar. Creating a new, empty calendar before importing, a step Apple's instructions mention as optional, makes every one of these reversible by deleting that calendar.

What to do next

Decide whether the goal is to move events or to see them. If events are moving, export .ics rather than an archive or spreadsheet, import one week into a new calendar first, and check time, repetition and placement before importing the rest. If the goal is simply to see several accounts in one place, no file is needed; Caltimate shows multiple accounts side by side, and the comparison with other calendars sets out the other options.