Time Zone Converter: Getting Meetings and Deadlines Right Across Zones
This converter takes a date and time in one zone and shows what the same moment reads as in as many other zones as you like. It uses the time zone database your browser already ships, the same one your operating system uses, so daylight saving is applied correctly for the date you picked rather than for today. Each row shows the offset, the weekday, whether the converted time falls on a different day and how many hours apart the two zones are at that moment.
Table of Contents
Zones Are Not Offsets
An offset is a number, a zone is a set of rules. UTC+1 says how far ahead of universal time a clock reads at one moment. Europe/Warsaw says which offset applies on any given date, including when it switches and by how much.
The same place has different offsets through the year. Warsaw is UTC+1 in winter and UTC+2 in summer. Booking something as UTC+2 in July gives you the wrong hour in November, which is the single most common cross border scheduling error.
The IANA database is the reference. Zones are named after a representative city rather than a country, because countries can contain several zones and because boundaries change. It records historical rules too, so converting a date in 1995 uses the rules that applied then.
Zone rules change more often than people expect. Governments alter daylight saving with little notice, and the database is updated several times a year. Your browser picks those updates up with system updates.
How to Use the Converter
Start with the source. The from zone defaults to your own, detected from your browser, and the date and time default to now. Set to now resets both to the current moment in whichever source zone you have chosen.
Add as many comparison zones as you need. Each appears as a row with the local reading, the offset in force at that moment and how far it sits from your source. Rows can be removed individually.
Watch the day marker. A row saying next day or previous day is the detail that causes missed meetings. Nine in the morning in London is six in the evening in Tokyo on the same day, but six in the evening in New York is seven the next morning in Tokyo.
Copy Comparison puts the whole table on your clipboard as plain text, which is what you want when sending a meeting invitation to people in several countries.
Daylight Saving and Why Dates Matter
Converting requires a date, not just a time. Asking what nine in the morning in London is in New York has no answer without knowing when, because the gap is five hours for most of the year and four hours during two short windows when the two countries change clocks on different weekends.
The changeover dates are not aligned. The United States moves in March and November, Europe in late March and late October. For roughly three weeks each year the usual difference between London and New York is an hour out, which quietly ruins recurring meetings.
The southern hemisphere runs the other way. Sydney is on daylight saving over the European winter, so the gap between London and Sydney swings between nine and eleven hours across a year.
Plenty of places do not observe it at all. Most of Asia and Africa, and within the United States both Arizona and Hawaii, keep one offset all year, which is why the difference to them moves twice a year even though their clocks never do.
The Hour That Happens Twice
When clocks go back, one local hour occurs twice. A time such as 01:30 on the changeover night is genuinely ambiguous, since it refers to two different instants an hour apart. This converter resolves it consistently by settling on one of them rather than guessing differently each time.
When clocks go forward, an hour does not exist. If the clock jumps from 02:00 to 03:00, then 02:30 never happens. Entering it produces the nearest real instant rather than an error.
This is why the conversion runs twice. The first pass estimates the instant, the second checks the offset actually in force at that instant and corrects if the estimate straddled a boundary. Skipping that step is how tools end up an hour out twice a year.
Avoid scheduling anything critical in that window. Aviation, finance and broadcasting all avoid the changeover hour entirely, which is sound advice for a payroll run or a deployment too.
UTC, GMT and Zulu
UTC is the standard, and it never changes. Coordinated Universal Time has no daylight saving, which makes it the sensible reference for anything technical.
GMT is a time zone, and Britain leaves it every summer. London is on GMT in winter and British Summer Time in summer, so writing GMT when you mean London time is wrong for half the year. The two are equal in winter and an hour apart in summer.
Zulu is the same thing in aviation and military use. The Z suffix on an ISO timestamp means UTC, which is why 2026-09-06T14:00:00Z needs no further explanation anywhere in the world.
Scheduling Across Zones
Name the zone, not the offset. Writing 15:00 Europe/Warsaw survives a clock change; writing 15:00 UTC+2 does not. Calendar invitations that carry a zone rather than an offset are the reason recurring meetings usually survive March and October.
Check the overlap before proposing a time. Between Europe and the American west coast there are perhaps three comfortable hours a day, and between Europe and Australia there are almost none, which is a scheduling fact rather than a scheduling problem to solve.
Share more than one reading. Sending a time in every attendee zone, which is exactly what Copy Comparison produces, removes the mental arithmetic and the errors that come with it.
Beware half hour and quarter hour zones. India runs at UTC+5:30, Nepal at +5:45 and parts of Australia at +9:30. Assuming whole hours quietly breaks the arithmetic for a sixth of the world.
Why Abbreviations Are Unsafe
They are ambiguous. CST is Central Standard Time in North America, China Standard Time and Cuba Standard Time, three different offsets. IST covers India, Ireland and Israel. A three letter code is not enough information to convert anything.
They also change with the season. New York is EST in winter and EDT in summer, so the abbreviation you wrote in January is wrong by June.
Use the IANA name. America/New_York, Asia/Kolkata, Europe/Dublin. It is unambiguous, it survives daylight saving and every serious system understands it.
Storing Times in Software
Store the instant in UTC. For anything that happened, a UTC timestamp is unambiguous and sorts correctly. Convert to a local zone only when displaying it.
Future events need the zone as well. A meeting a year from now, stored only as UTC, moves an hour if the government changes daylight saving rules in the meantime. Store the local time and the zone name so the intention survives.
Never store an offset in place of a zone. An offset is a snapshot of one moment and carries no rules, so it cannot be used to work out anything about a different date.
Keep the zone database current. Servers running an outdated release convert recent rule changes wrongly, which surfaces as times that are an hour out for one country and correct for everywhere else.
Common Mistakes to Avoid
Assuming the gap between two cities is constant. It moves whenever either side changes clocks, and the two rarely change on the same weekend.
Writing GMT when you mean London. Correct in winter, an hour wrong all summer.
Forgetting the date changes. Converting across the Pacific frequently moves the day, and the row marker here exists precisely because that is so easy to overlook.
Booking a recurring meeting by offset. It will drift by an hour twice a year for half the participants. Use a zone name in the calendar entry.
Frequently Asked Questions
On the changeover hour: Times inside a daylight saving transition are either ambiguous or nonexistent, and different systems resolve them differently. Avoid scheduling anything critical in that hour rather than relying on any tool to guess your intention.