Time Zone Converter
Enter a date and time in one time zone and see exactly what it is in another — Daylight Saving Time is worked out from the real calendar date you pick, on both ends, not a fixed offset.
Why time zone conversion needs a real date
Most of the world's time zones don't sit at a fixed distance from UTC year-round — Daylight Saving Time shifts the offset by an hour for part of the year in dozens of countries, and not every country changes on the same date (or changes at all). A converter that only knows "New York is UTC-5" will be an hour wrong for roughly seven months of the year, whenever Eastern Daylight Time (UTC-4) is actually in effect. This tool avoids that by asking your browser's own time zone database for the real offset on the exact date you entered — separately for the source zone and the destination zone — so the answer is correct whether both zones observe DST, only one does, or neither does.
Worked example
14:30 on August 14, 2026 in America/New_York — during Eastern Daylight Time, UTC-4 — converts to 21:30 the same day in Europe/Athens, which is on Eastern European Summer Time, UTC+3, at that date. The seven-hour gap comes entirely from each zone's DST status on August 14; run the same conversion for a January date instead, and New York drops to UTC-5 while Athens drops to UTC+2 — a seven-hour gap either way, but only because both zones happen to shift by the same one hour. Try a pair where only one side observes DST (Europe/London to Asia/Tokyo, for instance) to see the gap itself change between summer and winter.
Frequently asked questions
Does this handle Daylight Saving Time correctly?
Yes. The converter doesn't use a fixed UTC offset per zone — it asks your browser's own time zone database what the real offset was on the exact date you entered, for both the source and destination zone independently. That means a conversion involving America/New_York in July (Eastern Daylight Time, UTC-4) and the same conversion in January (Eastern Standard Time, UTC-5) both come out correct automatically, and so does the case where only one of the two zones observes DST.
Why do you need a date, not just a time?
Because the UTC offset for almost every time zone changes with the date — that's what Daylight Saving Time is. "3 PM in London" means something different in June (British Summer Time, UTC+1) than in December (Greenwich Mean Time, UTC+0). Without a specific date, a time zone converter can only guess, and it will be wrong for roughly half the year in any zone that observes DST.
What happens if I enter a time that doesn't exist, like 2:30 AM on a spring-forward day?
Clocks in DST-observing zones skip an hour forward once a year (in the US, clocks jump from 2:00 AM straight to 3:00 AM), so times in that skipped hour never actually occur locally. Browsers resolve this by treating the entered time as if the clock change had already happened, so 2:30 AM effectively becomes 3:30 AM in that zone's new offset — a reasonable, standard interpretation, but worth knowing if your result looks an hour off on a DST-transition day.
What about a time that happens twice, like 1:30 AM on a fall-back day?
Once a year, DST-observing zones repeat an hour (clocks fall back from 2:00 AM to 1:00 AM), so a time like 1:30 AM occurs once before the change and once after. This tool resolves the ambiguity using the offset that applies before the clocks fall back. If you specifically need the second occurrence, shift your input time forward by an hour and adjust manually.
Is my date and time sent to a server?
No. The entire conversion runs in your browser using the JavaScript Intl API and your browser's built-in time zone database — nothing you enter is transmitted, logged, or stored anywhere.