Calendar bridge

CSV → calendar

Paste or upload a spreadsheet of events. Each event keeps its local time in whatever timezone you specify — the .ics file has correct UTC timestamps so the event opens at the intended wall-clock time for every attendee.

Paste or upload (CSV or TSV)

Upload file

Detected delimiter: , · 6 columns, 5 rows

Column mapping

Title*Date (YYYY-MM-DD)*Time (HH:MM)IANA timezone*Duration (m/h)LocationDescription

5 valid · 0 errors

Standup2026-05-04 13:00 UTCAmerica/New_York
Product sync2026-05-04 13:00 UTCEurope/London
APAC all-hands2026-05-05 01:00 UTCAsia/Tokyo
Demo day2026-05-08 13:30 UTCEurope/Berlin
Quarterly review2026-05-12 05:30 UTCAsia/Kolkata

Questions

FAQ

Why does each event need a timezone column?: Because "3pm on March 15" is meaningless without a timezone. If you bulk-import events as naive local times, your calendar app guesses — usually by assuming your local zone, which silently mangles the schedule for events that are supposed to happen elsewhere. Forcing a timezone column makes the intent explicit and the .ics output unambiguous.
What date and time formats are accepted?: Date must be ISO YYYY-MM-DD (e.g. 2026-05-04). Time must be HH:MM in 24-hour clock (e.g. 14:30). Duration accepts plain minutes ("60"), suffixed minutes ("60m"), or hours ("1h", "1.5h"). Anything else is flagged as an error per row so you can fix it before downloading.
What timezone strings work?: Any IANA zone identifier — "America/New_York," "Europe/London," "Asia/Kolkata," etc. Friendly aliases like "EST" or "PST" are not accepted because they're ambiguous (EST also describes Australian Eastern Standard Time). If your spreadsheet has cities, map them to zones first via the Time Zone Converter or the city pages.
Will this work with Google Calendar imports?: Yes. The output is a standard RFC 5545 .ics file with UTC timestamps, one VEVENT per row, and a UID per event so re-imports update existing entries instead of duplicating. Google Calendar, Outlook, Apple Calendar, Fastmail, and Proton Calendar all import it correctly in our testing.

Related tools

FAQ

Why does each event need a timezone column?

Because "3pm on March 15" is meaningless without a timezone. If you bulk-import events as naive local times, your calendar app guesses — usually by assuming your local zone, which silently mangles the schedule for events that are supposed to happen elsewhere. Forcing a timezone column makes the intent explicit and the .ics output unambiguous.

What date and time formats are accepted?

Date must be ISO YYYY-MM-DD (e.g. 2026-05-04). Time must be HH:MM in 24-hour clock (e.g. 14:30). Duration accepts plain minutes ("60"), suffixed minutes ("60m"), or hours ("1h", "1.5h"). Anything else is flagged as an error per row so you can fix it before downloading.

What timezone strings work?

Any IANA zone identifier — "America/New_York," "Europe/London," "Asia/Kolkata," etc. Friendly aliases like "EST" or "PST" are not accepted because they're ambiguous (EST also describes Australian Eastern Standard Time). If your spreadsheet has cities, map them to zones first via the Time Zone Converter or the city pages.

Will this work with Google Calendar imports?

Yes. The output is a standard RFC 5545 .ics file with UTC timestamps, one VEVENT per row, and a UID per event so re-imports update existing entries instead of duplicating. Google Calendar, Outlook, Apple Calendar, Fastmail, and Proton Calendar all import it correctly in our testing.