Time Zone Converter

Q: Why does the offset for a city change depending on the date?

Because most of the world observes daylight saving, and the offset is a property of an instant rather than of a place. London is UTC+00:00 in January and UTC+01:00 in July. That is exactly why storing a fixed offset with a timestamp is a bug waiting to happen — a meeting saved as UTC+01:00 will be an hour wrong for half the year. Store the instant in UTC and the zone name separately, and let the conversion happen at display time.

Q: Should I use EST or America/New_York?

Always the zone name. EST is a fixed offset that only describes New York for part of the year — in summer the city is on EDT, an hour ahead. Abbreviations are also ambiguous: CST means three different things depending on whether you are in Chicago, Havana or Beijing. IANA zone names like America/New_York carry the whole history of that location's offsets and DST rules, so they resolve correctly for any date, past or future.

Q: Why do some conversions land on a different date?

Because zones can be more than a day apart when you account for the international date line. Auckland is thirteen hours ahead of London in the southern summer, so 9pm Monday in London is 10am Tuesday there. This tool always shows the full date alongside the time and explicitly flags when a conversion crosses into a different day, because scheduling mistakes of exactly this kind are extremely common and easy to miss when only the clock time is displayed.

Q: What happens to times that do not exist?

When clocks spring forward, an hour is skipped — in most of Europe, 01:30 simply does not occur on the changeover morning. When they fall back, an hour repeats, so 01:30 happens twice and a bare local time is genuinely ambiguous. These are real sources of production bugs in scheduling code, which is why anything running on a fixed local time needs testing against both changeover days rather than assuming every day has twenty-four hours.

Q: Are the conversions accurate for historical dates?

They use your browser's built-in timezone database, which carries the full historical record of offset and DST changes — so a date in 1970 resolves against the rules in force then, not today's. That database is updated with the browser, so a very recent political change to a country's timezone may lag if your browser is old. For anything critical involving dates in the far past, check against an authoritative source, since timezone history contains genuine oddities.

Q: Is UTC the same as GMT?

For practical purposes yes, and the difference almost never matters outside astronomy. UTC is an atomic time standard kept within a second of the Earth's rotation by occasional leap seconds; GMT is a time zone based on the Greenwich meridian. In everyday computing they refer to the same instant. The useful distinction is that UTC is what you should store and transmit, while GMT is a zone that some regions use as their local time and which, confusingly, shifts to BST in the British summer.

Convert a moment between time zones with the real offsets for that date, including daylight saving, and see when a conversion crosses a day boundary.

Date and time

In this zone

That moment elsewhere

Add a zone

Conversions use your browser's built-in timezone database, so nothing is sent to a server and historical dates resolve against the rules that applied at the time.

What It Does

Pick a moment and a zone, and see what the clock reads everywhere else you care about. The important part is that the offset is worked out for the specific date you enter rather than taken as a constant, because it is not one: most of the world shifts by an hour twice a year, and a conversion that ignores that is wrong for roughly half the calendar. The tool shows the resulting local time with its full date, states the offset in force at that instant, says whether daylight saving is active, and flags explicitly when the conversion lands on a different day — the failure mode behind a great many missed meetings. Everything resolves against your browser's timezone database, so historical dates use the rules that actually applied then.

When to Use It

You are scheduling a call across several offices and need to see the local time in each before you propose a slot.
A log timestamp is in UTC and you need to know what the clock read locally when the incident actually happened.
You are testing scheduling code and need to confirm what your system should produce on a daylight-saving changeover day.
A deadline is quoted in one zone and you need to know how much time remains where you are, including whether it falls on the next day.
You are writing documentation for an international audience and want the correct offset for a specific date rather than a guess.

Worked Examples

2026-07-15 14:00

Mid-summer, so the northern hemisphere is on daylight saving. London reads UTC+01:00 rather than its winter UTC+00:00 — the single most common source of an hour-out error in scheduling.

2026-01-15 14:00

The same clock time in January. London is back on UTC+00:00 while Sydney has moved to daylight saving, so the gap between the two cities is different from the summer figure by two hours.

2026-12-31 23:30

Late on New Year's Eve, chosen because it crosses the date boundary for most of the world. Zones ahead of you are already into the following year, which the tool flags rather than leaving you to spot.

Features

Convert between any IANA time zones

Correct offset for the specific date entered

Daylight saving detected and reported

Date-boundary crossings flagged explicitly

Multiple destination zones compared at once

Historical dates resolved against the rules of the time

Current offset shown for every zone

Your local zone detected automatically

Copy any converted result

Runs entirely in your browser

How to Use

1. Enter a date and time, or use the button to take the current moment. 2. Choose the zone that time is expressed in. 3. Add the zones you want it converted into. 4. Each result shows the local date and time, the offset in force, and whether daylight saving applies. 5. Watch for the day-change flag when zones are far apart.

Common Mistakes

Storing a fixed offset alongside a timestamp. The offset for a place changes with daylight saving, so a value saved as +01:00 is an hour wrong for half of every year.
Using abbreviations like EST or CST. They are ambiguous across countries and describe only part of the year — IANA zone names carry the full rules and resolve correctly for any date.
Assuming every day has 24 hours. Changeover days have 23 or 25, and code that adds 86400 seconds to get tomorrow will be an hour out twice a year.
Ignoring the date when converting. A large offset difference frequently pushes the result into the previous or next day, and reading only the clock time hides it.
Treating a local time on a changeover morning as unambiguous. When clocks go back, the same local time occurs twice, and one of them is not the one you meant.

Frequently Asked Questions

Why does the offset for a city change depending on the date?

Should I use EST or America/New_York?

Why do some conversions land on a different date?

What happens to times that do not exist?

Are the conversions accurate for historical dates?

Is UTC the same as GMT?