Inputs. Formula. A clear result.

Time zone converter

Convert a dated time between named time zones.

Your inputs

Example values — adjust to your situation

Uses browser time-zone data. A skipped local time must be corrected.

Your inputs stay in this browser.
Worked example

Time at destination

2026-10-20 21:00
Destination zone
Asia/Shanghai
UTC offset at destination
UTC+08:00
UTC instant
2026-10-20T13:00Z
See the formula below ↓
The details behind your result

How this calculation works

Convert an instant, not just a clock label

A time-zone conversion needs a date as well as a clock time. A location can use different UTC offsets at different times of year. Named zones such as America/New_York preserve that distinction, whereas a fixed label such as UTC−5 does not describe every date in New York.

Enter the local date and time at the source, select the source and destination zones, and choose how to interpret a repeated local time. The tool resolves the source to a UTC instant, then formats that instant in the destination zone. It shows the destination date, clock time, applicable UTC offset, and UTC reference so you can check whether the date changed.

Skipped and repeated local times

A forward clock change can skip a local time completely. The converter reports this rather than silently moving the meeting to another hour. A backward change can make the same clock label occur twice. Earlier and later select the two different instants, which can produce different destination times.

For example, on January 15, 2026, 09:00 in New York converts to 14:00 UTC and 22:00 in Shanghai under the relevant zone rules. On July 15, 2026, the same New York clock time corresponds to 13:00 UTC and 21:00 in Shanghai. The one-hour difference comes from the dated source offset, not from a change in the input clock label.

Time-zone rules are maintained in the IANA Time Zone Database and can change when governments change civil-time rules. This tool uses the database available through the browser's internationalization implementation. Keep the browser updated and reconfirm important future meetings if local rules change. It does not fetch a new time-zone database on each calculation.

Frequently asked questions

Why use a city-style name instead of CST?

Abbreviations can refer to different zones. A named IANA zone is less ambiguous.

Why is the destination on another date?

The same instant can fall before or after midnight in different zones.

Are historical offsets always exact?

The result is limited by the browser’s database and supported date range. Confirm historical research against specialist records.

Using and checking the result

All inputs and arithmetic on this page stay in the current browser. Switching between English and Chinese keeps the current form values in memory during navigation. Reloading the site restores the example. The toolkit does not save calculation inputs in cookies or browser storage, and the usage event records only that a calculation was completed, not the values or answer.

The initial values are a worked example, not a suggestion about your personal situation. Replace every relevant field before using the answer. Editing a field clears the previous result so it is not mistaken for a calculation using the new values. Use Reset example to return to the starting illustration.

If a result appears unexpected, repeat a small example by hand. Check units, signs, endpoints, and whether a percentage was entered as 30 rather than 0.30. To report an issue, use the contact form with non-sensitive sample inputs, the answer you expected, and the steps that produced the difference. Do not include private academic records or identifying details.

Plan a meeting across a clock change

The arithmetic relationship is UTC instant = source wall time minus its dated UTC offset. Destination wall time = that instant plus the destination offset at that instant. The difficult step is selecting the correct dated offsets, especially near a clock change. For a one-time meeting, decide which local schedule is the anchor. If the organizer fixes a meeting at 09:00 in New York on a specific date, convert that dated New York value to every participant's zone. Do not independently convert “09:00” without the date, and do not substitute your current local date if the meeting occurs later in the year. The clock rules at the meeting date are the relevant rules.

A recurring meeting raises a separate question. “Every Monday at 09:00 in New York” follows New York's local clock, so a participant elsewhere may see the meeting move when only one region changes its offset. “Every seven days at 14:00 UTC” follows a fixed UTC schedule and can move on the organizer's local clock instead. Both schedules are coherent, but they are different promises. Confirm the intended anchor with the organizer and enter each occurrence's date when checking it.

For travel, an itinerary's departure and arrival times are usually local to different places. Convert both endpoints to UTC before subtracting if you need elapsed travel time. Subtracting the printed clock readings can give a negative duration or a misleading short flight when the date line or a large offset is involved. This page converts one instant at a time; it does not infer which airport, date, or time zone an unlabeled itinerary intended.

Repeated local times deserve explicit communication. When a backward clock change makes 01:30 occur twice, a message containing only the date, place, and clock label may still be ambiguous. The UTC result shown here distinguishes the two occurrences. Share that UTC value or the applicable numeric offset along with the local appointment time when the distinction matters. For a skipped time, ask the organizer to choose an actual valid time rather than guessing a replacement.

You can check a conversion by reversing it. Take the destination date and clock result, make that zone the source, and convert back to the original zone. For an ordinary unambiguous time, the original value should return. Around repeated hours, keep the same occurrence; otherwise a different instant may be selected even though the local clock label looks unchanged. A conversion to the same named zone should also preserve the input clock value, except that it still validates whether the local time exists.

Finally, browser data can lag a recently announced rule change. The tool exposes the numeric UTC offset so you can compare it with a current official local notice or the organizer's calendar. Updating the browser can update its time-zone data, but no browser-based converter can guarantee a future government will keep today's rules unchanged. Reconfirm important future events close to the date.