Time Zone Calculator

Two steps: local time to UTC, then UTC to local time

Every conversion on this page runs through Coordinated Universal Time, usually written UTC. UTC is the reference clock that never moves: no country applies daylight saving to it, and every zone is described as an offset from it. One subtraction turns a local clock reading into UTC, and one addition turns UTC into the target clock reading.

The sign belongs to the offset, not to the city. New York in July is UTC-04:00, so subtracting that offset adds four hours: 14:30 minus negative four is 18:30. Tokyo is UTC+09:00, so the second step adds nine hours to 18:30 and lands at 27:30, which rolls over to 03:30 on the next calendar day. The rollover is the step people forget, and it is why a 14:30 call in New York reaches Tokyo at breakfast the following morning.

The calculator does that arithmetic for you and prints the intermediate UTC value, so you can check each step against a world clock. It also reports the offset difference directly, because two zones can be 13 hours apart while their clocks show times that look much closer.

Offsets that are not whole hours

Most zones differ from UTC by a whole number of hours, which makes mental arithmetic easy. Not all of them do. India runs on UTC+05:30 with no daylight saving, Nepal sits at UTC+05:45, and the Chatham Islands east of New Zealand use UTC+12:45 in winter and UTC+13:45 in summer. None of those offsets can be written as a whole hour, so a converter that works in hours alone will be wrong by 30 or 45 minutes.

This calculator stores every offset in minutes rather than hours, so half-hour and quarter-hour zones convert exactly. Kolkata and Kathmandu are both in the zone list, and a 12:00 departure from Kolkata arrives on the Kathmandu clock at 12:15, a 15 minute shift that a whole-hour tool would report as no change at all.

Quarter-hour offsets also show up in the Pacific. The Chatham Islands are 45 minutes ahead of New Zealand's main islands, which is easy to miss when you book a ferry or a domestic flight from Auckland.

Daylight saving moves the offset, not the zone

Daylight saving time adds 60 minutes to the standard offset for part of the year. The zone itself does not change and neither does its name in the database; the offset used on a given date does. That is why a converter needs the date as well as the time: 09:00 in New York is 14:00 in Berlin in January and 15:00 in Berlin in July.

The United States rule is set by federal law and administered by the Department of Transportation: clocks go forward at 02:00 on the second Sunday in March and back at 02:00 on the first Sunday in November. NIST, which distributes official US time, lists the same two dates for 2026, March 8 and November 1, and notes that the current rule has applied since 2007. The European Union follows Directive 2000/84/EC, which fixes the change at 01:00 UTC on the last Sunday in March and the last Sunday in October, so the local clock hour differs between member states even though the instant is shared.

Southern hemisphere zones run the other way around: daylight saving covers their summer, which falls in the northern winter. Sydney is UTC+10:00 in July and UTC+11:00 in January, the reverse of Berlin's pattern.

A worked conversion from New York to Tokyo

Take 14:30 on Wednesday, July 15, 2026 in New York. The date falls inside the US daylight saving window, so the offset is UTC-04:00 rather than UTC-05:00. Subtract the offset to reach UTC: 14:30 plus 4 hours is 18:30 UTC on the same Wednesday.

Tokyo has no daylight saving and sits at UTC+09:00 all year. Add nine hours to 18:30 and you get 27:30, which is 03:30 on Thursday, July 16. The whole trip takes one arithmetic step per zone plus a rollover check, and the answer carries both a new clock time and a new weekday.

A winter example behaves differently. 09:00 on Thursday, January 15, 2026 in Los Angeles is UTC-08:00, so UTC is 17:00. London in January is on GMT, UTC+00:00, so the London clock also reads 17:00. The eight hour gap between the two cities in January shrinks to seven hours in July, when Los Angeles moves to UTC-07:00 and London moves to UTC+01:00.

Those two examples use four of the seventeen zones in the list. The same two steps cover the rest: find the offset for the date, subtract it, then add the target offset and adjust the calendar day if the total passes midnight in either direction.

One instant, several desks

Meeting planning is easier if you fix one instant and read every clock against it. The table below takes 18:30 UTC on Wednesday, July 15, 2026 and shows what each office sees. Every row is the same moment; only the offset changes.

Read down the table and the pattern is obvious: a single 18:30 UTC slot reaches Los Angeles and New York in the working day, lands in the European evening, and sits in the middle of the night for India, Japan and Australia. No single hour works for all eight cities, which is why distributed teams rotate the inconvenient slot instead of pretending one time suits everyone.

The calculator prints the same set of reference clocks under the result, so you can test a candidate hour before you send the invitation.

Missing hours and doubled hours

The two changeover days each break the clock in a different way. On the spring date the local clock jumps from 01:59 to 03:00, so every reading between 02:00 and 02:59 does not exist. On the autumn date the clock falls from 01:59 back to 01:00, so every reading between 01:00 and 01:59 happens twice.

The calculator handles both cases explicitly. A skipped time returns an error naming the zone and the date, because there is no honest answer to give. A doubled time returns a warning and uses the earlier of the two readings, which is the daylight time pass, and the warning states which reading was chosen.

Two timestamps in the same city can therefore differ by an hour while the clock face reads the same. When a deadline falls in that window, write it in UTC and the ambiguity disappears.

The two changeover calendars do not line up

The United States and the European Union change clocks on different Sundays, so there are weeks each year when their usual gap is one hour wider or narrower than the rest of the year. In 2026 the US moves on March 8 and the EU on March 29, which leaves three weeks when New York is on daylight time and London is still on GMT.

Those four weeks are where recurring meetings drift. A standup booked as 09:00 New York and 14:00 London is correct for most of the year, then arrives an hour early for London during the mismatch, then returns to normal. Booking the series in UTC, or re-checking the offset after each changeover, avoids the drift entirely.

Australia adds a third calendar. Sydney leaves daylight time on April 5 and returns to it on October 4, so the Sydney to London gap moves on yet another pair of dates.

What the calculator covers, and what it does not

The zone list holds seventeen entries: Honolulu, Anchorage, Los Angeles, Denver, Chicago, New York, London, Berlin, Moscow, Dubai, Kolkata, Kathmandu, Bangkok, Shanghai, Tokyo, Sydney and Auckland. Each one carries a standard offset in minutes and a daylight rule, and the rules used here are the 2026 rules for the United States, the European Union, southern Australia and New Zealand. The underlying offsets follow the IANA time zone database, the public data set that most operating systems and programming languages use; its 2026e release was published on September 29, 2026.

Three limits are worth stating plainly. First, the calculator does not model historical rules, so a date before 2007 in the United States will use the current March and November dates rather than the April and October dates that applied then. Second, it does not include every exception: Arizona and Hawaii skip daylight time, and a few countries change their rules with little notice. Third, zones that are not in the list, including Chatham Islands, Newfoundland and Central Australia, need their offset entered by hand or a lookup in the full database.

For anything that involves money, contracts or travel documents, check the offset against the IANA database or the national time authority for the date in question. The rules change more often than most people expect: a single government decision can move a whole country's offset, and the database is updated to match.