Time Zone Converter

A world clock that converts a time across cities and shows the difference at a glance.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Moves a specific date and time from one city's clock to another's, showing the converted time, the same instant in UTC, and the offset between the two zones.

How to use it

1Set the Date & Time field — it opens pre-filled with your device's current local time.
2Choose the From and To zones from the twenty-six cities listed.
3Read the converted time, the UTC line and the offset difference in the panel below; the World Clock underneath ticks along live.

Example

Input: 1 Aug 2026, 09:00 — From UTC, To Kolkata (IST)
Output: 2:30:00 pm the same day, with "Offset difference: +5.5 h" beneath it

Half-hour and quarter-hour zones are handled properly, hence the 5.5 rather than a rounded 5 or 6. Dates and times are formatted in your browser's own locale, so the same result may print as 14:30:00 on a machine set to a 24-hour format.

What happens to your data

Offsets are not looked up over the network: they are derived by formatting the instant with Intl.DateTimeFormat in the target zone and measuring how far the result has moved, using the IANA rules the browser already ships. That means daylight saving is applied as it stood on the date you entered rather than as it stands today. Your own zone is used only to pre-fill the date field on load, is never reported, and nothing you enter survives a refresh.

Last updated August 2026

Almost every time zone question is really a scheduling question with something at stake: a call with colleagues eight hours away, a deadline that expires at midnight in another country, a webinar you would rather not join an hour late. Doing the sum in your head works until daylight saving moves one of the two cities and not the other, which happens more often than people expect.

This moves one specific date and time between twenty-five cities, with UTC itself as a twenty-sixth option, and prints the gap between them as a number. The offset is worked out for the date in the box rather than for today, so it gets the awkward stretches right: London is four and a half hours behind Kolkata in August and five and a half in January, and the answer changes with the date without you having to remember why.\n\nA timezone converter earns its keep on the days the arithmetic quietly changes. Any time converter can subtract five and a half hours; what matters is that the two places involved may move their clocks on different weekends, so the gap you memorised last month is wrong this month. Convert time zones on the date of the meeting rather than today.

How it works

Toolvore resolves the conversion in two passes, because the time you type is not yet a moment in history — 09:00 becomes a real instant only once you say whose clock it is. The first pass reads your input as though it were UTC, measures the source zone's offset near that point and subtracts it, which gives the instant. The second pass measures the destination zone's offset at that instant and formats the result there. Both measurements come from Intl.DateTimeFormat and the IANA rules your browser already ships with, so no zone database is fetched and nothing you type is sent anywhere. The arithmetic stays in minutes and is only divided by sixty at the end, which is why Kolkata comes out as +5.5 rather than a rounded 5 or 6. The weak point is the word "near" in that first pass: the source offset is sampled a full offset away from the instant it describes, which costs nothing on an ordinary day but breaks on the day the From city moves its clocks — a run of hours next to the switch, as many of them as that city sits from UTC, comes out an hour wrong. The FAQ below gives the exact window for New York.

Common use cases

Scheduling a call across offices so it lands in someone's working day rather than the middle of their night
Working out when a deadline quoted in another country's time falls on your own clock
Turning a meeting invitation written in UTC into the hour you actually need to be free
Checking a date months ahead, when the gap between two cities may not be the one it is today
Glancing at the world clock for the current time in New York, London, Kolkata and Tokyo

Frequently asked questions

Which cities can I convert between?＋

Twenty-six entries: UTC at the top of both lists, then twenty-five cities running from Honolulu and Anchorage through to Sydney and Auckland. They are a fixed dropdown — there is no search box and no way to type an IANA zone name of your own, which is the tool's main gap in coverage. If your city is missing, substitute one that shares its rules rather than merely its offset this week: Toronto keeps identical time to New York all year, and Amsterdam to Berlin, so either swap is safe. Phoenix is the cautionary case — it never changes its clocks, so it matches Denver in January and Los Angeles in July, and picking the wrong stand-in puts you an hour out for half the year.

Why doesn't the converted time match my own clock?＋

Because the two fields start out of step, and this catches nearly everyone. The date box fills itself with your device's local wall clock when the page loads, but the From box starts on UTC — so an untouched page reads your local time as though it had been UTC all along, and the UTC line hands your own clock straight back to you. That is only correct if you happen to live in UTC. Set From to your own city before you read anything and the numbers line up.

Does it handle daylight saving?＋

It reads the rules for the date in the box rather than for today, which is the part that matters. India does not change its clocks and the United Kingdom does, so London sits four and a half hours behind Kolkata in August and five and a half in January. The gap can also move for three weeks at a stretch between two countries that both observe it: America springs forward on 8 March 2026 and Britain not until 29 March, so London to Los Angeles reads -8 h on 1 March, -7 h on 15 March, and -8 h again on 1 April. There is one honest exception, and it is the changeover day in the From city. Type 03:30 in New York on 8 March 2026 and the UTC line reads 08:30 when the true answer is 07:30 — everything from 02:00 to 06:59 that morning comes out an hour late, and from 07:00 it is right again. The 1 November change goes wrong the same way in the opposite direction. The destination city is handled correctly on its own changeover day; it is only the city you convert from, so check anything you schedule on a date a clock moves.

What are the UTC line and the offset difference telling me?＋

The UTC line is your converted moment written in Coordinated Universal Time, which is what you want when a third person is involved or when a system logs in UTC. The offset difference is the destination's UTC offset minus the source's, so it is simply the hours to add or subtract. Because it is a real subtraction in minutes rather than a lookup, half-hour zones print honestly as +5.5, a far-apart pairing such as Honolulu to Auckland in January prints +23 h and lands you on the next day — noon on 15 January becomes 11:00 on the 16th — and two cities on the same clock print "same" instead of 0 h.

Can I add my own cities to the world clock?＋

No. It is fixed at five — UTC, New York, London, Kolkata and Tokyo — labelled with their IANA identifiers rather than friendly names, ticking once a second. You cannot add, remove or reorder them. It is also as close as this page comes to showing several places at once: there is no grid for finding the one hour that suits three time zones, because the converter handles a single pair at a time.

Is anything I type sent anywhere?＋

No. Every offset is measured by your own browser from the zone rules it already carries, so once the page has loaded a conversion needs no network at all, and nothing about the date, the cities or your location is transmitted. Nothing you enter is kept, either — reload and the date and the two cities go back to their defaults.