How is the offset calculated?

The tool uses the Intl.DateTimeFormat API built into modern browsers to read the UTC offset for each selected time zone at the current moment, then subtracts one from the other.

Does it account for Daylight Saving Time?

Yes. The offset is computed for the current date and time, so DST transitions are reflected automatically. The DST badge shows whether DST is currently active in each zone.

What counts as 'business hours' in the meeting planner?

Business hours are defined as 09:00–17:00 local time. Green slots mean both zones are in business hours; yellow means one zone is; red means neither is.

How many time zones are available?

All major IANA time zones are listed, covering every country and territory worldwide.

Time Zone Offset Calculator

このツールについて

Select any two IANA time zones from the searchable dropdowns and instantly see the current local time in each zone, the hour offset between them, and whether Daylight Saving Time is currently active. The 24-hour meeting planner highlights each hour of the day in green (business hours for both zones), yellow (business hours for one zone), or red (outside business hours for both), making it easy to schedule calls and meetings across continents.

使い方

1 Select the first time zone from the 'Zone A' dropdown (type to search).
2 Select the second time zone from the 'Zone B' dropdown.
3 View the current local time, UTC offset, and DST status for both zones.
4 Scroll to the 24-hour meeting planner to see color-coded overlap blocks.
5 The clocks update automatically every second.

What a time zone offset is

A time zone offset is how far a region's local clock sits from UTC (Coordinated Universal Time), the global reference. New York in winter is UTC−05:00, meaning its clocks read five hours behind UTC; India is UTC+05:30 — and that half-hour reminds us offsets are not always whole hours. The number that matters when scheduling across two places is the difference between their offsets, which this tool computes live for any pair of IANA time zones (like America/New_York and Asia/Tokyo) you pick from the searchable dropdowns.

How the offset is calculated

Rather than store a static table that goes stale, the tool reads each zone's offset from your browser's built-in internationalization engine (Intl.DateTimeFormat) for the current moment. It asks the engine what the local time is in each zone right now, compares that to UTC, and the gap in minutes is the offset. The headline difference is one offset minus the other. Because it always uses the current instant, the result already reflects whatever rules — including Daylight Saving Time — are in force today.

A worked example

Pick America/New_York as Zone A and Europe/London as Zone B in early June. New York is on Eastern Daylight Time, UTC−04:00; London is on British Summer Time, UTC+01:00. The difference is −4 − (+1) = −5 hours, so the badge reads that New York is 5 hours behind London. Note that for most of the year the gap is the same 5 hours, but during the two- to three-week windows in spring and autumn when one country has switched clocks and the other has not, the difference briefly becomes 4 or 6 hours. This is exactly the kind of trap a live, date-aware calculation avoids and a memorised "5 hours" does not.

How Daylight Saving Time is detected

The DST badge is inferred, not looked up from a list of rules. For each zone the tool computes the UTC offset on January 1 and on July 1 of the current year. The smaller of the two is taken to be standard time; if the offset right now is larger than that standard value, the zone is currently observing DST. This works correctly for both hemispheres — in the Southern Hemisphere summer falls in January, and the logic still picks the right standard baseline. Zones that never change clocks (much of Asia, Arizona, UTC itself) show the same offset in both months, so the badge correctly reads "No DST".

The meeting planner explained

Below the clocks, a 24-cell strip maps every hour of the day to a color so you can spot overlap at a glance:

Green — it is business hours (09:00–16:59) in both zones. This is your ideal call window.
Yellow — business hours in only one of the two zones. Workable, but someone is starting early or staying late.
Red — outside business hours in both. Avoid unless someone is willing to take a night call.

For New York and London, the green band typically lands in the early-to-mid afternoon London time, which is mid-morning in New York — the familiar transatlantic sweet spot. For New York and Tokyo, a 14-hour gap, you will see little or no green, which is the planner honestly telling you a comfortable shared window barely exists.

Practical use cases

Scheduling international calls without doing offset arithmetic in your head.
Coordinating remote teams spread across continents to find the few overlapping working hours.
Planning live events, webinars, or launches so you can announce a time that lands sensibly in multiple regions.
Catching DST surprises before they cause a missed meeting during the spring and autumn transition weeks.

Common mistakes to avoid

Assuming the offset never changes. A fixed "8-hour difference" breaks twice a year when only one side has shifted clocks. Always check on or near the actual meeting date.
Confusing a city with its country. Large countries span several zones — pick the specific IANA city closest to the person, not the capital by default.
Ignoring date rollover. A green slot can fall on a different calendar day in the two zones; the date shown under each clock tells you which.
Treating 9-to-5 as universal. The planner uses 09:00–17:00 as a sensible default, but real working hours vary by culture and role — use it as a starting point, then confirm with the people involved.

Everything is computed locally in your browser from the current system clock and the browser's time-zone database. No location data is sent anywhere.