Math & Dates Time zone converter
Convert a time across as many cities as you need at once, with daylight saving resolved for the actual date you entered.
| Zone | Local time | Offset | Difference |
|---|---|---|---|
| UTCsource | Thu 10 Sept, 09:00 | UTC+00:00 | 0 h |
| America/New York | Thu 10 Sept, 05:00 | UTC−04:00 | -4 h |
| Europe/London | Thu 10 Sept, 10:00 | UTC+01:00 | +1 h |
| Asia/Jakarta | Thu 10 Sept, 16:00 | UTC+07:00 | +7 h |
| Asia/Tokyo | Thu 10 Sept, 18:00 | UTC+09:00 | +9 h |
Add or remove zones
Offsets are resolved for the exact date you entered, so daylight saving is handled correctly, including the weeks when the northern and southern hemispheres disagree, and the transition dates that differ between the US and Europe.
Ready. Runs locally on your device.
Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.
Share result
Cite
Cite this page
Reembun. (2026, July 28). Time zone converter. https://reembun.com/timezone-converter
How to use it
Set the moment
Date, time, and In this zone describe the instant you are converting from.
Add the zones you care about
Pick the cities the other people are in. Add as many as the meeting needs.
Read the columns
Each zone shows its local time and its date, so a call that lands on tomorrow for someone is impossible to miss.
Copy the list
Copy all takes every zone as text, ready to paste into a calendar invitation.
How the conversion works
The tool resolves your entered wall-clock time in the source zone to an exact instant, then formats that instant in every zone you have selected.
That first step is less trivial than it looks. Finding the UTC instant corresponding to “09:00 in Berlin on 25 October” requires knowing the offset in Berlin at that moment, which depends on whether daylight saving was in effect, which depends on the instant you are trying to find. The resolution is done in two passes: an initial estimate, then a correction using the offset at the estimated instant. A single pass is wrong for times within an hour of a transition.
Why fixed offsets fail
Storing “London is UTC+0” is wrong for seven months of the year. Storing “New York is 5 hours behind London” is wrong for about three weeks of it.
| Period | London → New York |
|---|---|
| Most of the year | −5 hours |
| Mid-March to late March | −4 hours |
| Late October to early November | −4 hours |
The gaps exist because the EU and the US change their clocks on different dates. Any scheduling logic built on a fixed offset will be wrong twice a year, and the failures cluster exactly when people are least expecting them.
The southern hemisphere problem
Australia and New Zealand observe daylight saving in the opposite half of the year, so offsets between hemispheres swing rather than shift.
| Period | London → Sydney |
|---|---|
| Northern summer | +9 hours |
| Overlap periods | +10 hours |
| Northern winter | +11 hours |
A recurring London-Sydney call at a fixed London time moves by two hours across the year in Sydney. This is why calendar invitations should carry a zone rather than an offset.
Zones that are not whole hours
| Zone | Offset |
|---|---|
| India | UTC+05:30 |
| Iran | UTC+03:30 |
| Nepal | UTC+05:45 |
| Newfoundland | UTC−03:30 |
| Chatham Islands | UTC+12:45 |
| Marquesas | UTC−09:30 |
Any system assuming offsets are whole hours breaks for a substantial share of the world’s population. India alone is over 1.4 billion people.
Practical advice for scheduling
Name a zone, not an offset. “09:00 Jakarta time” survives a daylight saving change; “09:00 UTC+7” does not necessarily.
Send calendar invitations, not times in prose. Calendar software resolves the zone for each attendee. An email saying “3pm” starts a thread.
Check the date, not just the cities. Two cities that are five hours apart today may be four hours apart next month.
For recurring cross-hemisphere meetings, expect drift. Agree in advance whose local time is fixed and whose moves.
Common questions
Does this handle daylight saving?
Yes, and for the date you entered rather than today. That distinction matters when scheduling weeks ahead: a 09:00 London call is 04:00 in New York for most of the year but 03:00 during the fortnight in autumn when the two regions have not both changed clocks yet.
Why do the US and Europe change clocks on different dates?
Because they legislate independently. The EU changes on the last Sunday in March and October; the US on the second Sunday in March and the first in November. That leaves roughly three weeks each year when the usual offset between them is an hour different from normal.
What about the southern hemisphere?
Australia and New Zealand run daylight saving in the opposite half of the year to Europe and North America, so the offset between Sydney and London swings by two hours across the year rather than staying fixed. Scheduling a recurring call between hemispheres without checking is how meetings drift.
Should I store times as UTC?
For events that have already happened, yes. A UTC timestamp is unambiguous. For future scheduled events, store the local wall-clock time plus the zone identifier instead, because time zone rules change by legislation and the correct UTC instant may change before the event arrives.
Last reviewed
