Time zone converter.

Convert time zones, accurately

Convert a time from one zone to another with daylight saving handled for you. Pick a source zone, a target zone, and a date; the answer uses IANA time-zone rules instead of a fixed UTC shortcut.

Example for Thursday 5 November 2026: 9:00 AM in New York is 2:00 PM in London, 11:00 PM in Tokyo and 7:30 PM in Mumbai.

The interactive converter loads here in your browser. Pick any two zones, a date and a time.

Convert the timestamp, then decide what to do with it

One timestamp

Convert a webinar, deadline, interview, game, release, or flight update from the host timezone into the timezone you actually use.

DST-sensitive dates

Pick the real date instead of relying on a fixed UTC offset, especially around March, October, and November clock changes.

Shareable context

Create a link when the converted time will be read by people in several places and you want their browser to show the local result.

How to convert time zones

The method, and the cases it has to get right

The converter above does this for you, but the logic is worth understanding: it is what stops a meeting landing on the wrong day or the wrong hour.

The mental model: go through UTC

Every conversion is two steps. First, subtract the source zone's offset to get the universal time (UTC). Then add the destination zone's offset. New York at UTC-05:00 and London at UTC+00:00 means the gap is 5 hours — but thinking in "gaps" breaks down across daylight saving, so the reliable model is always source to UTC to destination.

Convert the date, not just the clock

Offsets span a 26-hour range, from UTC-12:00 to UTC+14:00. A late- evening time converted eastward easily lands on the next calendar day, and an early-morning time converted westward lands on the previous one. Always carry the date through the conversion — a correct hour on the wrong day is still a missed meeting.

Daylight saving changes the gap

The hour gap between two cities is not constant. New York and London are normally 5 hours apart, but because their daylight-saving switch dates differ, the gap is 4 hours for two or three weeks in March and one week around the start of November. Pin the conversion to a specific date so the right rule is applied for that exact day.

Opposite hemispheres run opposite seasons

When the northern hemisphere springs forward, the southern hemisphere falls back. London and Sydney can be 9, 10, or 11 hours apart depending on the month. There is no single "Sydney is X hours ahead" answer — this is exactly why conversions must run off named IANA zones, never a remembered offset.

The fall-back hour is ambiguous

When a region turns its clocks back in autumn, one local hour happens twice — 1:30 AM occurs before and after the shift. A bare local time in that window is genuinely ambiguous. If you are scheduling near a transition, work in UTC or attach the IANA zone so there is exactly one answer.

Half-hour and quarter-hour offsets

Not every offset is a whole hour. India is UTC+05:30, Nepal is UTC+05:45, and parts of Australia use UTC+08:45. A conversion that assumes whole-hour math will be 30 or 45 minutes wrong for these regions. The converter handles fractional offsets automatically because it reads them from the IANA data.
Anchor saved times to a UTC instant plus an IANA zone, never to a remembered hour gap.

Four conversions, step by step

Each example uses standard (non-DST) offsets so the arithmetic is clear. The note says how daylight saving changes the result; use the converter above for a specific date.

New York→London

9:00 AM in New York is 2:00 PM in London (standard time).

  1. New York standard time is UTC-05:00; London standard time is UTC+00:00.
  2. The gap is 5 hours, with London ahead.
  3. Add 5 hours to 9:00 AM: the meeting lands at 2:00 PM the same day.

DST: Both cities observe daylight saving but change on different dates, so the gap is 4 hours instead of 5 for two or three weeks in March and one week around the start of November.

San Francisco→Tokyo

4:00 PM Monday in San Francisco is 9:00 AM Tuesday in Tokyo (standard time).

  1. San Francisco standard time is UTC-08:00; Tokyo is UTC+09:00 year-round.
  2. The gap is 17 hours, with Tokyo ahead — large enough to cross the calendar date.
  3. Add 17 hours to 4:00 PM Monday: the result is 9:00 AM the next day, Tuesday, in Tokyo.

DST: Japan never observes daylight saving, so when San Francisco is on daylight time the gap narrows to 16 hours from mid-March to early November.

London→Sydney

10:00 AM in London is 9:00 PM in Sydney (northern winter / southern summer).

  1. London standard time is UTC+00:00; Sydney in southern summer is UTC+11:00 (it observes DST).
  2. The gap is 11 hours, with Sydney ahead.
  3. Add 11 hours to 10:00 AM: the result is 9:00 PM the same day in Sydney.

DST: Sydney and London sit in opposite hemispheres, so their daylight-saving seasons are reversed. The gap swings between 9, 10, and 11 hours across the year — this pair is the clearest case for anchoring to IANA zones rather than a fixed offset.

UTC→India (Mumbai)

12:00 noon UTC is 5:30 PM in India.

  1. India Standard Time is UTC+05:30 — a half-hour offset, with no daylight saving.
  2. Add 5 hours 30 minutes to 12:00 noon UTC.
  3. The result is 5:30 PM the same day across all of India.

DST: India uses a single half-hour offset nationwide and never changes clocks, so this conversion is the same every day of the year.

Where time zone conversions go wrong

The repeated "fall back" hour

When clocks turn back in autumn, one local hour occurs twice. A plain local time in that window, such as 1:30 AM on the changeover night, does not identify a single instant. The converter uses the first occurrence; schedule in UTC or keep the IANA zone attached if the second one matters.

The missing "spring forward" hour

In spring, clocks jump ahead and one local hour never happens. 2:30 AM on that date in that region is not a real time; the converter reads it with the offset in force just before the change, which equals 3:30 AM after the jump.

Recurring meetings across a DST change

A weekly call fixed in one city's clock will appear to move in other cities during the weeks when their DST schedules are out of step. Check the time on each side in March and in late October and early November.

Frequently asked questions

How do I convert a time to another time zone?
Pick the source city or zone, set the date and time, then pick the target city or zone. The result shows the converted time and the date there, so a late-evening time in New York correctly shows as the next morning in Tokyo.
Does the converter handle daylight saving time?
Yes. It uses IANA time zone IDs, which carry each region's real daylight-saving schedule, and applies the offset in force at the exact date and time you enter rather than a fixed UTC offset.
Why do results shift by an hour on some dates?
That is usually daylight saving time. If you move the date across a clock change, one zone may shift while the other stays the same. New York and London, for example, are 4 hours apart instead of 5 for two or three weeks in March and one week around the start of November.
Can I convert a past or future date?
Yes. The IANA database includes historical rules and announced future changes. Future dates use the rules known today, so a government change announced later can alter the answer.
Does it handle half-hour and 45-minute zones?
Yes. India (UTC+05:30), Iran (UTC+03:30), Myanmar (UTC+06:30), Nepal (UTC+05:45) and other non-hour offsets are converted to the minute.
Can I share a converted time as a link?
Yes. After you change the zones or the time, the address bar holds the source zone, the target zone and the moment you entered. Anyone who opens that link sees the same conversion.

Converter or meeting planner?

Use the converter for one moment: what does this clock reading mean over there? Use the meeting planner when several people need a working-hours window that suits everyone, and the world clock to keep an eye on several cities at once.

Time zone and daylight-saving rules come from the IANA Time Zone Database, applied by your browser and our server. How we source and calculate times