Time zone converter

Wall-clock time vs. the instant

The whole job of a time zone converter is to keep a single physical instant fixed while changing how it reads on the clock. When you enter “3:00 PM in New York”, that's a wall-clock time; the tool works out which absolute moment that is, then asks “what does that same moment read as in Tokyo?” Both displays point at the identical instant — only the label differs. That distinction is why you can't just add a fixed number of hours: the offset between two zones isn't constant through the year.

Why daylight saving makes this hard

Countries start and end daylight saving on different dates — and some don't observe it at all — so the gap between, say, London and New York is usually 5 hours but briefly 4 around the spring and autumn switches when one side has changed and the other hasn't. Getting it right means knowing each zone's rules for the specific date you picked, not just its name. This converter reads those rules from the IANA time-zone database built into your browser, so a meeting set for next March is converted with next March's offsets, not today's.

The gap and the overlap

Twice a year a wall-clock time gets weird. On spring-forward night an hour simply doesn't exist (clocks jump 02:00 → 03:00), and on fall-back night one hour happens twice. The tool resolves your input in two passes so it lands on a real instant even near those transitions. It's the reason recurring calendar events can drift by an hour after a DST change — the event is pinned to a wall-clock time, and the offset under it moved.

Finding a slot that works everywhere

The world-clock strip shows your chosen instant across a dozen common cities at once, so a 4 PM London call is visibly breakfast in California and late evening in Singapore before you send the invite. If you'd rather work with absolute Unix timestamps — the timezone-free form used in logs and APIs — switch to the epoch converter.