Does this handle daylight saving time?

Yes. It resolves the offset for the exact date you enter using the browser's IANA time zone database, so a date in March gives a different answer from one in January where the rules differ.

Why does Arizona have its own entry?

Because most of Arizona does not observe daylight saving. It stays on Mountain Standard Time year round, so it matches Denver in winter and Los Angeles in summer.

Time Zone Converter

Convert a date and time between any two time zones, with daylight saving handled automatically.

Draft — figures checked, awaiting an editorial read. Not indexed.

Local time there—

Your time: —
Difference: —
Offset: — hours

Formula: The entered wall time is resolved to a UTC instant using the source zone's offset on that date, then re-formatted in the target zone.

What this calculates

This converts a specific date and time from one time zone to another, which is the calculation behind every scheduled international meeting. It uses real time zone data rather than fixed offsets, so daylight saving is handled correctly for the date you enter — and that matters, because the offset between two places is not constant. New York and London are five hours apart most of the year but four hours apart for two weeks in March and one in late October, when one has changed clocks and the other has not.

How it works

The date and time you enter are treated as a wall clock reading in the source zone. That is resolved to an absolute UTC instant by looking up the source zone's offset on that specific date, then correcting once more in case the first guess landed on the other side of a daylight saving transition. The resulting instant is then formatted in the target zone. All of this runs against the browser's built-in IANA time zone database, so the rules stay current without this page shipping any data of its own.

Worked example

A 2:00 pm meeting in New York on a date in January, converted to London. New York is on Eastern Standard Time at UTC−5, so 2:00 pm is 19:00 UTC. London is on Greenwich Mean Time at UTC+0, so it shows 7:00 pm — five hours ahead. Run the same 2:00 pm meeting in July and both cities are on summer time, so the gap is still five hours and London shows 7:00 pm. But on 20 March, when the US has switched and the UK has not, the gap is four hours and London shows 6:00 pm.

Common mistakes

Assuming the offset between two places is fixed. Countries change clocks on different dates and some do not change at all — Arizona stays on standard time year round, which is why it is listed separately here. Second, using an abbreviation like "CST" as an identifier: it means US Central Standard Time, China Standard Time, or Cuba Standard Time depending on who is writing. Third, scheduling across a transition weekend without checking, which is where most missed calls actually come from.

Common questions

Does this handle daylight saving time?: Yes. It resolves the offset for the exact date you enter using the browser's IANA time zone database, so a date in March gives a different answer from one in January where the rules differ.
Why does Arizona have its own entry?: Because most of Arizona does not observe daylight saving. It stays on Mountain Standard Time year round, so it matches Denver in winter and Los Angeles in summer.