Time Zone Converter

Background.

Pick two places, a date and a time, and this converter tells you what the clock reads at the other end — with daylight saving worked out for you. That last part is the entire difficulty of time zone conversion, and it is why the date is an input: New York is five hours behind UTC in January but four in July, so "what time is 12:00 New York in Nairobi" has two different answers depending on the day. On 15 January it is 20:00; on 15 July it is 19:00, because Nairobi never shifts and New York does.

This is also why the dropdowns list places rather than offsets. An offset is not a stable fact about a location — it is a fact about a location on a date. The stable identifier is the zone name, which is how the IANA Time Zone Database organises the world's clocks: Africa/Nairobi and America/New_York name regions with a shared civil-time history, and the database records every rule those regions have used and will use, including the exact weekends daylight saving begins and ends. Asking you for a city is not a convenience wrapper around asking for an offset; it is asking for the thing that is actually constant.

The offsets are not stored in this page either. They are resolved at calculation time from that same IANA database — the reference every operating system, browser and scheduling tool uses — via the JavaScript runtime on your device, which keeps its copy current. Countries really do change their rules: in recent years alone, rule changes and daylight-saving abolitions have come from Mexico, Egypt, Iran, Jordan and Syria, and each shipped to the world's devices as a database update rather than as something every website had to notice. When that happens, the conversion here follows automatically. That is also why the result panel shows each zone's resolved UTC offset for your chosen date: it is the converter showing its working, so you can see that 15 July resolved New York to -4, not the -5 a static table would have used.

The day-shift output answers the question that actually causes missed calls: not "what time is it there" but "is it already tomorrow there." A 20:00 call in Los Angeles is a 07:00 call in Nairobi the next morning — the +1 tells you that at a glance, and it works across month and year boundaries, so a 23:30 New Year's Eve call from Los Angeles correctly lands on 1 January in East Africa. For recurring meetings the seasonal version of the same trap applies: the US changes clocks in mid-March, Europe at the end of March, and the southern hemisphere moves the opposite way, so a New York-London pairing slides by an hour for two weeks every spring while a New York-Nairobi pairing shifts by an hour for a whole season.

Two boundary cases are handled the way scheduling tools handle them. A time that never exists at the source — 02:30 in New York on the March morning clocks jump from 02:00 to 03:00 — rolls forward across the gap. And half-hour and quarter-hour zones are first-class: India is +5:30, Nepal +5:45, and the Chatham Islands +12:45 in winter and +13:45 in their summer. The dropdown covers about forty major zones worldwide; if you need a location that is not listed, the entry sharing its capital or nearest major city almost always shares its clock — Mombasa keeps Nairobi's time, all of India keeps Kolkata's.

What is time zone converter?

A time zone is a region that shares one civil clock, defined by its offset from Coordinated Universal Time (UTC). Offsets are not always whole hours — India runs at +5:30 and Nepal at +5:45 — and in much of the world the offset itself changes twice a year with daylight saving time, which is what makes conversion genuinely error-prone.

The authoritative record of every zone's rules, past and future, is the IANA Time Zone Database, which identifies zones by names like Africa/Nairobi rather than by numbers, precisely because the number is not constant. This converter works from those identifiers: it turns your source date and time into an exact universal instant using the source zone's rules for that date, then reads that instant back through the destination zone's rules. Both steps use the database as shipped and updated by your device's runtime, so the conversion stays correct without this page maintaining any table of offsets.

How to use this calculator.

1. 01Pick the date at the source location. It matters whenever either zone observes daylight saving.
2. 02Enter the time in 24-hour format — 13 for 1 PM, 23 for 11 PM.
3. 03Choose the source and destination from the dropdowns; each is a major city standing for its zone.
4. 04Read the destination clock time, and check the day shift: +1 means it is already tomorrow there.
5. 05Glance at the two resolved UTC offsets to see what daylight-saving state each zone was in on that date.
6. 06For a recurring meeting, check a January date and a July date — if the zones shift on different schedules, the meeting moves.

The formula.

Conversion is a two-step resolution through the IANA database, not offset arithmetic. Step one finds the exact universal instant at which the source zone's wall clock reads your chosen time on your chosen date. This is a lookup of the zone's rules for that date — standard or daylight time, and the offset in force. Step two formats that same instant in the destination zone's rules, giving the hour, minute and calendar date a person there would read.

Working at the level of instants rather than offsets is what makes the hard cases fall out correctly. Day shift is the difference between the two calendar dates, so it survives month and year boundaries. Fractional offsets need no special handling — the database simply says +5:45 for Kathmandu. And the one genuinely undefined input, a source time inside a daylight-saving spring-forward gap (02:30 in New York on the jump morning, a time no wall clock ever shows), is resolved by rolling forward across the gap — the convention used by calendar and scheduling software.

The resolved offsets shown in the result are derived from the same instant, which is why they can differ from the "famous" offset for a place: EST is -5, but on a July date the page will show -4, because the instant fell in EDT. If the offsets shown surprise you, that is the daylight-saving correction doing its job.

A worked example.

Frequently asked questions.

References& sources.

1. [1]IANA. Time Zone Database — the authoritative record of zone rules and transitions. Retrieved 2026-08-08. independence: primary; access: open.
2. [2]Ecma International. ECMA-402, ECMAScript Internationalization API Specification — the Intl interface this page resolves zones through. Retrieved 2026-08-08. independence: primary; access: open.
3. [3]BIPM. Coordinated Universal Time (UTC) — the reference scale offsets are defined against. Retrieved 2026-08-08. independence: primary; access: open.
4. [4]NIST. Time and Frequency Division, UTC FAQ. Retrieved 2026-08-08. independence: secondary-check; access: open.
5. [5]MDN Web Docs. Intl.DateTimeFormat — runtime documentation for zone-aware formatting. Retrieved 2026-08-08. independence: secondary-check; access: open.