--- title: "ICS Timezone Convert" description: "Move the events in an .ics calendar to another time zone, keep their clock times in a new zone when the export stated the wrong one, or rename Windows time zone names such as Eastern Standard Time to IANA names. All-day events stay as they are. On this page, nothing is uploaded." url: https://findutils.com/convert/ics-timezone-convert/ category: convert --- # ICS Timezone Convert Move the events in an .ics calendar to another time zone, keep their clock times in a new zone when the export stated the wrong one, or rename Windows time zone names such as Eastern Standard Time to IANA names. All-day events stay as they are. On this page, nothing is uploaded. **Use this tool:** [ICS Timezone Convert](https://findutils.com/convert/ics-timezone-convert/) ## Programmatic access - REST id `ics-timezone-convert`: POST https://api.findutils.com/api/tools/ics-timezone-convert/execute (reference: https://findutils.com/api/ics-timezone-convert/) - MCP tool `ics_timezone_convert` on https://mcp.findutils.com (reference: https://findutils.com/mcp/ics-timezone-convert/) - Data: 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. ## 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. ## 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](https://findutils.com/productivity/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](https://findutils.com/convert/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. ## Related Tools - [ICS Privacy Scrub](https://findutils.com/convert/ics-privacy-scrub/) - [ICS Busy/Free](https://findutils.com/convert/ics-busy-free/) - [Merge ICS](https://findutils.com/convert/merge-ics/) - [ICS to JSON](https://findutils.com/convert/ics-to-json/) - [Timezone Converter](https://findutils.com/productivity/timezone-converter/) - [Split ICS](https://findutils.com/convert/split-ics/)