Skip to content
ToolBoxGenie

Time Zone Converter

Converters · Added 12 August 2026

Convert a specific date and time from one city to another, with daylight saving applied as it stood on that date rather than as it stands today. The result shows whether it lands on a different calendar day, and a table gives you the same moment across nine major zones at once.

Entered as the wall-clock time in the source zone below.

How to use the time zone converter

  1. 1Set the date and the time. Both default to now, in your own zone.
  2. 2Choose the city you are converting from and the city you are converting to.
  3. 3Read the converted time, with the UTC offset and zone abbreviation for both ends.
  4. 4Watch for the 'next day' or 'previous day' badge — that is the detail that ruins meeting invitations.
  5. 5Use the table underneath to see the same instant everywhere else, or Swap to reverse the direction.

Examples

A New York morning meeting

Input
9:00 am on 15 July in New York, converted to India
Result
6:30 pm the same day in Mumbai

New York is on daylight time in July, so the gap is 9½ hours rather than 10½.

The same meeting in January

Input
9:00 am on 15 January in New York, converted to India
Result
7:30 pm the same day in Mumbai

India has no daylight saving, so the gap changes purely because New York's clocks moved.

Crossing the date line

Input
9:00 pm on 15 July in New York, converted to Sydney
Result
11:00 am on 16 July — the next day

This is where scheduling goes wrong: the time looks reasonable and the date is not the one you meant.

About the time zone converter

Offsets are not a property of a place

The instinct is to treat a time zone as a fixed number attached to a country: India is +5:30, Germany is +1. For India that happens to hold, because it does not observe daylight saving. For Germany it is true for roughly half the year and wrong for the other half.

An offset is really a property of a place at an instant. That is why this converter asks for a date before it will give an answer, and why a conversion done in advance for a recurring meeting can quietly drift: the two ends may change their clocks on different weekends, so a call that was 9am to 5:30pm all year moves twice, by an hour each time, and neither party did anything.

Scheduling across zones without the mistakes

The reliable habit is to agree the moment, not the wall-clock time. Send a calendar invitation rather than a time in a message: an invitation carries the zone with it and every recipient's software renders it correctly, including after a clock change. A time typed into an email carries nothing and has to be re-interpreted by whoever reads it.

Where you do have to write a time down, write the zone next to it and use the date explicitly. 'Tuesday 9am ET (Wednesday 6:30pm IST)' is unambiguous and takes a moment to produce. 'Tuesday morning' across nine and a half hours is not a time at all — and for anything spanning the date line, naming both dates is the difference between a meeting and an empty room.

Frequently asked questions

Does this handle daylight saving?
Yes, and for the date you entered rather than for today. That distinction matters when you are scheduling across a clock change: converting a March meeting using November's offset puts it an hour out. The offsets come from the IANA time zone database that your browser already carries.
Why is the difference between two cities not a whole number of hours?
Because several zones are not offset by whole hours. India is UTC+5:30, Nepal is UTC+5:45, and parts of Australia are on :30 and :45 offsets too. Any tool that assumes whole hours is wrong for well over a billion people.
What if the time I entered does not exist?
When clocks spring forward, an hour of local time is skipped entirely — 2:30 am simply never happens on that date. The converter flags this and uses the instant immediately after the jump, rather than silently returning a time that did not occur.
Why is my city not in the list?
The list is a curated set of major zones rather than all four hundred-odd IANA identifiers, most of which are aliases of one another. Any city shares its zone with a larger one nearby — pick the listed city in the same zone and the result is identical, because the offset is a property of the zone rather than the city.