时区转换

Why "what time is it there?" is harder than it sounds

Converting a time between two places is not a simple matter of adding hours. The offset between two cities can change several times a year because of daylight saving time (DST), and not every country observes it — or observes it on the same dates. New York is normally five hours behind London, but for a few weeks each spring and autumn the two regions switch clocks on different days, so the gap briefly becomes four or six hours. Hard-coding "London = UTC+0" will give you the wrong answer for half the year. This tool sidesteps that problem entirely by using the IANA timezone database built into your browser through the JavaScript Intl.DateTimeFormat API, which knows the historical and current DST rules for every named zone.

Zones, not abbreviations

The tool works with IANA zone identifiers like America/New_York, Europe/London, and Asia/Tokyo rather than abbreviations like EST or BST. This matters: an abbreviation such as "CST" is ambiguous — it can mean Central Standard Time in North America, China Standard Time, or Cuba Standard Time, three completely different offsets. A zone identifier is unambiguous and carries the full rulebook, including when and whether that location shifts for DST. When you pick a reference city, set a date and time, and add other cities, each row is formatted in its own zone for that exact moment, so the displayed times already account for whichever DST state applies on the date you chose.

A worked example

Imagine you want a call at 9:00 AM on a Tuesday in New York and need to know when that is elsewhere. Set the reference zone to America/New_York, the date to that Tuesday, and the time to 09:00. The planner then shows the equivalent local moment in each city you have added:

Because Tokyo never shifts its clocks but New York does, the offset between them is not constant across the year — the tool resolves it correctly for the specific date you entered.

Good for

• Scheduling meetings across teams. Pick a slot that is daytime for everyone before sending a calendar invite, instead of discovering afterward that it landed at 3 AM for a colleague.
• Planning live events and launches. Announce a webinar or product drop with the correct local time for each audience region.
• Catching DST gotchas. Check the week of a clock change to confirm whether the usual offset still holds — this is exactly when scheduling mistakes happen.
• Coordinating travel. Work out arrival times and whether a connecting flight crosses into the next calendar day.

Tips and pitfalls

• Mind the date, not just the time. A morning meeting in the Americas is often the same evening — or the next day — in Asia and Oceania. Always read the date alongside the time when a conversion crosses midnight.
• The reference zone defaults to your device. The tool starts from your computer's own timezone setting. If that is wrong (for example, a laptop still set to a previous trip's location), every result shifts with it. Confirm the reference zone first.
• Half-hour and 45-minute offsets are real. India is UTC+5:30 and parts of Nepal are UTC+5:45. Never assume offsets are whole hours when planning around South Asia.
• Schedule by zone, not by offset. If you agree on "UTC+1" instead of a named city, a future DST change can quietly move the meeting. Agreeing on a city keeps the intent intact.

Where the calculation runs

Everything happens locally. The conversions use the IANA timezone data that ships with your browser, so no clock, location, or schedule is sent to any server — the planner works the same with your network disconnected. Because the rules come from your browser's bundled database, keeping your browser and operating system reasonably up to date ensures the latest DST changes (which governments occasionally revise) are reflected.