ICS Timezone Convert

Mode

Target time zone

Also anchor floating times

Each event keeps its moment in time: 09:00 in Los Angeles becomes 12:00 in New York. UTC times are restated in the target zone too.

Drop .ics files hereor click to choose calendar exports

Converted calendar

The converted calendar will appear here.

How to Change the Time Zone of an ICS File

Pick the mode

Convert instants keeps each event's moment; Re-anchor wall-clock keeps each event's clock time; Normalize Windows TZIDs only renames zone names.
Pick the target time zone, such as America/New_York

The list starts on your own zone. Normalize does not need one.
Drop the .ics file

The preview shows each event's start before and after, and the warnings list what was left unchanged and why.
Download the converted .ics and import it

The file keeps every UID, so importing it into the same calendar updates the existing events.

Common Use Cases

Fix an Outlook export whose Windows zone names make Google Calendar or Apple Calendar place events an hour off

Move a conference schedule published in the organizer's zone into your own zone before importing it

Repair an export from a device set to the wrong zone, where the clock times are right but the zone is not

Restate a calendar stored in UTC in the zone of the people who read it

Give floating-time events, which have no zone, the zone they were meant for

Why Convert the Time Zones in an ICS File?

A calendar file states each time with a zone: a TZID such as America/Los_Angeles, a trailing Z for UTC, or nothing at all for floating time. When that zone is wrong, or is a name the importing app does not know, every event lands at the wrong hour. Outlook writes Windows zone names such as Eastern Standard Time, which some calendar apps do not recognize; an export made on a laptop set to the wrong zone states the right clock times in the wrong place; and a calendar planned in one city is easier to read in another city's time. Fixing that by hand means rewriting every DTSTART and DTEND and the time zone definitions that go with them. This page does it for every event in the file and writes a matching time zone definition.

Convert instants reads each date-time in the zone it states, places it on the UTC timeline and restates it in the target zone. DTSTART, DTEND, DUE, RECURRENCE-ID, EXDATE and RDATE are all rewritten, so a recurring event's exceptions still match its occurrences. A time that falls in the hour skipped when clocks spring forward is read with the offset before the gap, and a time that occurs twice when clocks fall back is read as the first one, as the iCalendar standard, RFC 5545, specifies. Re-anchor keeps the clock numbers and changes only the zone, and moves a recurrence end (UNTIL) the same way. Normalize renames zone names and changes no time.

The zone rules come from your browser's time zone database through the standard Intl API, with no library. That decides what the page can and cannot do. It knows IANA names such as Europe/Istanbul and their common aliases. It does not know Windows zone names, so the page carries its own table that maps the Windows IDs Outlook writes, such as Eastern Standard Time or W. Europe Standard Time, to IANA names; display names such as (UTC-05:00) Eastern Time are not in it. Vendor paths such as /mozilla.org/20050126_1/America/New_York are read by their IANA part. Any other name is reported and left alone. The rules inside a file's own VTIMEZONE block are not read; the browser's rules for the named zone are used instead.

For every zone the output now names, the page writes a VTIMEZONE built from the same rules: the offset changes in the years the calendar covers, collapsed into a yearly rule where they repeat. Time zone blocks no longer referenced are dropped. All-day dates are never changed, floating times change only when you ask, and UIDs, alarms and every other property are kept, so importing the result updates the original events. No calendar URL is fetched.

How it compares

A world clock converts one time you type. This page rewrites every time in a calendar file, with the exceptions, recurrence ends and time zone definitions that go with them, which is what an importer needs. Editing the file by hand means converting each value, getting the daylight saving days right and writing a VTIMEZONE block yourself. For a single meeting time between two cities, the Timezone Converter is the faster tool.

Time Zone Tips

Convert instants is the right choice when the export is correct and you want it shown in another zone; Re-anchor is for an export that stated the wrong zone.
All-day events are dates, not times, so they are never moved; the warnings list how many were left as they are.
Recurring events keep their rule. Convert keeps the rule's end (UNTIL) as it was; Re-anchor moves it with the clock times so the series ends on the same local time.
A zone name nothing recognizes, such as a custom Outlook zone, is listed in the warnings and its events are left unchanged.
This page uses your browser's own time zone rules. A zone whose rules changed after your browser was released is computed with the older rules.

Frequently Asked Questions

What is the difference between Convert instants and Re-anchor wall-clock?

Convert instants keeps the moment: a 09:00 meeting in Los Angeles becomes 12:00 in New York, the same instant written in another zone. Re-anchor wall-clock keeps the clock time: 09:00 in Los Angeles becomes 09:00 in New York, a different instant. Use Convert when the export is right and you want it in another zone, and Re-anchor when the export stated the wrong zone for times that are otherwise correct.

Why do my imported events show up an hour off?

Usually because the importing app reads the time zone differently from the app that wrote the file. Outlook writes Windows zone names such as Eastern Standard Time that some apps do not recognize, and an export from a device set to the wrong zone states the right times in the wrong place. Normalize fixes the first case by renaming the zones to IANA names; Re-anchor fixes the second.

Which Windows time zone names are recognized?

The Windows zone IDs that Outlook and Exchange write in TZID, such as Eastern Standard Time, Pacific Standard Time, GMT Standard Time, W. Europe Standard Time, India Standard Time and AUS Eastern Standard Time, each mapped to the IANA zone of its main city. The table lives in the page because browsers do not know Windows names. Display names such as (UTC-05:00) Eastern Time (US & Canada) are not mapped, and a name the table does not hold is listed and left unchanged.

What happens to all-day events?

Nothing. An all-day event is stated as a date with no time of day, so there is nothing to convert, and moving it could shift it to the wrong day. All-day events are copied unchanged in every mode, and the warnings say how many there were.

How are daylight saving changes handled?

Each time is converted with the offset in force on its own date, so an event on the day the clocks change gets the right offset for that day. A time that does not exist because clocks sprang forward is read with the offset before the change, and a time that happens twice because clocks fell back is read as the first one, both as RFC 5545 specifies. The rules come from your browser's time zone data.

What does Also anchor floating times do?

A floating time has no zone: it means the same clock time wherever the calendar is opened. By default floating times are left as they are, and the calendar's X-WR-TIMEZONE hint is kept because importers read floating times with it. Turn the option on to state every floating time in the target zone with the same clock numbers; the X-WR-TIMEZONE hint then follows the target.

Does the converted file include a VTIMEZONE definition?

Yes. For every zone the converted file names, the page writes a VTIMEZONE built from your browser's rules for that zone: the offsets and changeover dates in the years the calendar covers, written as a yearly rule where they repeat. Definitions that no event uses any more are dropped. The rules inside the original file's VTIMEZONE blocks are not used for the conversion.

Are recurring events, exceptions and alarms kept?

Yes. The RRULE is kept and never expanded. EXDATE, RDATE and RECURRENCE-ID values are converted the same way as the start, so exceptions keep matching their occurrences. In Re-anchor mode the rule's end, UNTIL, moves with the clock times. Alarms, UIDs and every other property are copied unchanged, so importing the result into the same calendar updates the original events.

How is this different from the Timezone Converter?

The Timezone Converter shows what time it is, or will be, in several cities for a time you type. This page rewrites the times inside an .ics calendar file and writes a file you can import. To remove the details from a calendar before sharing it, use ICS Privacy Scrub.

Is my calendar uploaded when I use this page?

Not on this page. The files are read and converted in your browser with its own time zone data, and you can confirm in the browser's network panel that no request carries the calendar text. The page never fetches a calendar URL either. The REST API and MCP tool are a separate path: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

Can I convert time zones from a script?

Yes. The same code runs on the FindUtils REST API and MCP server as the ics_timezone_convert tool. Send the .ics text as input with mode set to convert, reanchor or normalize, target_tz set to an IANA name for convert and reanchor, and include_floating if you want floating times anchored, then read the calendar from the ics field with the counts, mappings and warnings.

Run it from code

$ curl -X POST \
  api.findutils.com/api/tools/ics-timezone-convert/execute \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"input":"BEGIN:VCALENDAR\nVERSION:2.0\nBEGIN:VEVENT\nUID:[email protected]\nDTSTART;TZID=America/Los_Angeles:20260701T090000\nDTEND;TZID=America/Los_Angeles:202…'

$ claude mcp add findutils \
  --transport http https://mcp.findutils.com/ \
  --header "Authorization: Bearer YOUR_API_KEY"
# then call findutils:ics_timezone_convert

Running a tool needs an API key. Keys are not for sale yet: ask for early access. About API keys

The REST API and the MCP tool are a separate path from this page: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

API reference Add to Claude