Time Tools

Time Zone Converter

Convert a wall-clock time between two time zones and see the offset, the gap, and whether daylight saving applies.

Start here Enter the date and time as it appears on the clock in the first zone.

Date and timeFrom this zoneTo this zone

4 hours behind

America/New_York is 4 hours behind of UTC at this moment.

UTC: Sat, 15 Aug 2026, 09:22 (UTC, UTC+00:00)
America/New_York: Sat, 15 Aug 2026, 05:22 (EDT, UTC-04:00)
Same instant in UTC: 2026-08-15T09:22:00.000Z
Daylight saving: No / Yes

Understand the format

How Time Zone Converter works

The gap between two time zones is not a fixed number. It changes whenever either zone starts or ends daylight saving, which is why recurring meetings drift twice a year.

An offset belongs to an instant, not to a zone

People say "New York is five hours behind London", but that is only true for part of the year. A time zone is a set of rules, not a fixed number: Europe/London is UTC+0 in winter and UTC+1 in summer, and America/New_York is UTC-5 and UTC-4. The offset you get depends on which instant you ask about, which is why this page asks for a date as well as a time.

That is also why storing an offset is not the same as storing a zone. If you save "+01:00" you have recorded what the clock said once; if you save "Europe/London" you have recorded the rule, and next year's answer will still be right. For future events, always store the zone.

The three weeks when everything breaks

The United States and Europe do not change their clocks on the same date. In 2026 the United States moves on 8 March and Europe on 29 March, leaving three weeks where London and New York are four hours apart instead of five. The southern hemisphere reverses the whole arrangement, so the gap between London and Sydney swings between nine, ten, and eleven hours across the year.

This page reports the gap for the instant you chose and warns you when the two zones do not keep that gap all year. If you are scheduling something recurring, that warning is the one to read: a meeting fixed at "14:00 London, 09:00 New York" will be wrong for three weeks unless the calendar stores zones rather than offsets.

Not every zone is a whole hour from UTC

India is UTC+5:30, Nepal is UTC+5:45, and the Chatham Islands are UTC+12:45. Newfoundland runs at UTC-3:30. Any code that assumes offsets are whole hours, or that stores them as an integer number of hours, is wrong for hundreds of millions of people.

Lord Howe Island goes further and shifts by thirty minutes for daylight saving rather than the usual hour. These are not curiosities to be handled later; they are the cases that make a bespoke offset table unmaintainable and a proper time zone database essential.

Step by step

How to use Time Zone Converter

Enter the date and time as it appears on the clock in the first zone.
Choose the zone that time belongs to, then the zone you want it in.
Read the difference and each zone local time, with its UTC offset and abbreviation.
If a warning appears, the gap between these zones is not constant across the year, so check the specific date you care about.

The conversion uses the Intl APIs in your browser, with the time zone rules your device already has. Nothing is sent anywhere.

Worked examples

Time Zone Converter examples explained

The usual five-hour gap

Input

15 January 2026, 09:00 in Europe/London

Result

Thu 15 Jan 2026, 04:00 in America/New_York (EST, UTC-05:00)

Both zones are on standard time in January, so the familiar five hours applies.

The same pair three weeks later

Input

25 March 2026, 09:00 in Europe/London

Result

Wed 25 Mar 2026, 05:00 in America/New_York (EDT, UTC-04:00)

The United States has already moved to daylight saving and Europe has not, so the gap is four hours. A meeting fixed by offset is now an hour out.

Reference

Offsets that break the "whole hours" assumption

Offsets that break the "whole hours" assumption
Zone	Standard	Daylight saving	Note
Asia/Kolkata	UTC+05:30	None	Half-hour offset, no daylight saving at all.
Nepal (Asia/Katmandu)	UTC+05:45	None	Forty-five minutes, fifteen ahead of India.
Australia/Lord_Howe	UTC+10:30	UTC+11:00	Shifts by thirty minutes, not an hour.
Pacific/Chatham	UTC+12:45	UTC+13:45	Forty-five minutes past a whole hour.
America/St_Johns	UTC-03:30	UTC-02:30	Newfoundland, half an hour from its neighbours.
Asia/Shanghai	UTC+08:00	None	One zone across the whole country.

Practical Guide

How teams use Time Zone Converter

Common use cases

Work out what your meeting time is for a colleague or customer in another country.
Check whether a scheduled job runs at the hour you expect in the region it serves.
Explain to a support caller why a timestamp in a log does not match their local clock.
Confirm the offset for a specific date rather than trusting a remembered rule.

Checks before trusting the result

The answer applies to the date you entered; the gap may differ next month.
Store zones rather than offsets for anything in the future.
Remember that abbreviations such as CST are ambiguous; the IANA name is not.

Troubleshooting

Common mistakes and how to fix them

Storing "+01:00" instead of "Europe/London" for a future event.: An offset is a snapshot. When the clocks change, every future event you saved that way is an hour out.
Assuming the gap between two cities is constant.: It changes when either zone switches. Recalculate for the actual date, especially in March, April, October, and November.
Using an abbreviation such as CST or IST in data.: CST is Central Standard Time, China Standard Time, and Cuba Standard Time. IST covers India, Ireland, and Israel. Use the IANA identifier.
Treating offsets as whole hours in a database column.: Store minutes, or better, store the zone name. India, Nepal, and Chatham all break the whole-hour assumption.

FAQ

Time Zone Converter questions, answered

Why does the difference change depending on the date I enter?

Because daylight saving changes each zone offset at different times of year. The gap between two zones is only meaningful for a specific instant.

Should I store a time zone or an offset?

Store the zone, such as Europe/London, for anything in the future, because the rules can change. An offset is fine for recording an instant that has already happened, alongside the UTC time.

What is the difference between GMT and UTC?

For everyday purposes they are the same. UTC is the modern time standard; GMT is a time zone that happens to equal UTC in winter. British clocks are on GMT in winter and BST in summer, so "GMT" is not a safe label for UK time year round.

Where does the zone data come from?

From the IANA time zone database built into your browser, so it reflects whatever rules your system has been updated with rather than a table baked into this page.

Why does the tool ask for a date and not just a time?

Because the offset depends on the date. Without one, any answer would be a guess about which side of a daylight saving change you meant.

Go deeper

Specifications and guides

Unix Time, Time Zones, and Expiry Bugs — Why tokens expire immediately, jobs run twice a year at the wrong hour, and two people see different dates for one record.