Last updated 3 September 2026
How this handles daylight saving
Time zone conversion isn't a fixed offset — many places shift by an hour for part of the year, and not always on the same dates as each other. This uses your browser's own time zone database, the same one your operating system relies on, so daylight saving is handled automatically for whatever date you pick, not just today.
Where time zones usually catch people out
The arithmetic is the easy part. What trips up scheduling is daylight saving, because countries move their clocks on different dates — and some do not move them at all. For a few weeks each spring and autumn the gap between two cities is an hour off what it is the rest of the year, which is exactly when recurring meetings quietly drift.
Offsets are not all whole hours either. India runs at half past, Nepal at forty-five minutes past, and parts of Australia sit on the half hour too. Anything that assumes a whole-hour difference will be wrong for a sizeable slice of the world.
When you confirm a time with someone, name the city rather than the abbreviation. Letter codes are ambiguous — CST alone covers North America, China and Cuba — while "3pm in Karachi" cannot be misread.
Why time zones are harder than adding hours
Offsets are not fixed properties of a place. Daylight saving shifts many of them twice a year, and the switch dates differ by country — the United States and Europe change on different weekends, so for a few weeks each spring and autumn the gap between New York and London is one hour different from usual. Meetings scheduled across that window are a reliable source of missed calls.
Not everywhere observes it at all. Most of Asia, Africa and South America do not, so the offset between London and Delhi changes twice a year purely because of what London does. Some offsets are not whole hours either: India is UTC+5:30, Nepal UTC+5:45, and parts of Australia UTC+9:30. And rules change by legislation, which is why software carries a regularly updated time zone database rather than a fixed table.
Scheduling that holds up
The habit that prevents most problems is to write times with their zone attached and never in bare local time. 14:00 UTC is unambiguous; 2pm my time is not, and neither is 2pm EST in July, when the correct label is EDT. For a recurring meeting, remember that a series fixed in one participant's local time will drift for everyone else when either country changes its clocks.
For genuinely distributed groups, look for the overlap window rather than a single ideal hour — the range where everyone's working day intersects is usually only two or three hours wide across three continents, and knowing where it sits is more useful than negotiating each meeting separately. Anything outside it means someone is taking the call early or late, and rotating who that is tends to work better than fixing it on the same person permanently.
Common questions
Does this handle daylight saving time?
Yes — it uses your browser's own timezone database, which accounts for each region's current daylight saving rules automatically, including places that don't observe it at all.
What time zone is the date and time I enter in?
Your own — the browser's local time zone, detected automatically. Every other row shows what that same moment looks like elsewhere.
Can I compare more than three places at once?
Yes, add as many as you need with the Add time zone button, and remove any you don't need.
Why does the time difference between two cities change during the year?
Because daylight saving changes on different dates in different countries, and many countries do not observe it at all. For a few weeks each spring and autumn the usual gap between two cities can be an hour different from normal.
What is the safest way to write a time for an international meeting?
State the zone explicitly, ideally in UTC alongside local times. Bare local times are ambiguous, and abbreviations such as EST are frequently used incorrectly during the summer months when EDT applies.
Are all time zone offsets whole hours?
No. India is UTC+5:30, Nepal is UTC+5:45, and parts of Australia and Canada use half-hour offsets. Assuming whole hours is a common source of scheduling errors across South Asia in particular.