Date & Time Converter

What a time zone conversion has to get right

Adding or subtracting hours is not a time zone conversion. The offset between two places is not constant: it depends on the date, because daylight saving starts and ends on different days in different countries, and some places do not observe it at all. This converter takes a date and time in one zone and returns the correct wall-clock time in another, along with the weekday, the zone abbreviation and the UTC offset that actually applied on that date.

It reads the full IANA time zone database from your browser — over four hundred zones — rather than a short hardcoded list, so cities with unusual offsets and historical rules are handled properly.

A worked example, and the week the usual answer is wrong

09:00 on 15 July 2026 in New York is 14:00 in London the same day, because New York is on EDT (UTC−04:00) and London is on BST (UTC+01:00) — a five-hour gap. The same 09:00 on 15 January is also 14:00 in London, this time with New York on EST (−05:00) and London on GMT (+00:00). Different offsets, same five-hour difference.

Now take 25 October 2026. The UK put its clocks back that morning; the US does not until 1 November. Noon in London on that date converts to 08:00 in New York, a four-hour gap — while noon on 20 October converts to 07:00, the usual five. For that one week the familiar "London is five hours ahead" is simply wrong, and a meeting scheduled by adding five hours is an hour out.

Zones with fractional offsets work the same way: the same 09:00 New York time is 18:30 in Kolkata (UTC+05:30) and 22:00 in Tokyo (UTC+09:00, no daylight saving at all).

How the conversion is performed

The date and time you type are interpreted as wall-clock time in the source zone, which is resolved to a single absolute instant using the offset in force in that zone on that date. That instant is then formatted in the destination zone using its own rule for the same date. Everything passes through the absolute instant, which is why an offset that changes between the two dates cannot corrupt the answer.

The zone data comes from the operating system, and the rules are updated as governments change them — which they do, with little notice and sometimes retroactively.

The two local times that do not behave

Twice a year, a local wall-clock time is either missing or repeated, and no converter can be fully correct about it because the input is genuinely ambiguous.

• When clocks go forward, an hour never happens. 02:30 on 8 March 2026 does not exist in New York; the converter resolves it to 03:30 EDT, moving it past the gap.
• When clocks go back, an hour happens twice. 01:30 on 1 November 2026 occurs once on EDT and again an hour later on EST; the converter resolves it to the first of the two.
• Where this matters — a scheduled job, a shift handover, a legal deadline — the safe practice is to state the moment in UTC and let each reader convert it.