What Is a Time Zone, Really?
A time zone is a rulebook, not a number. It defines what the local clock shows at any given instant for a geographic region — including which UTC offset applies in winter, which applies in summer if the region observes daylight saving, and exactly when the switches happen. The rulebooks live in the IANA time zone database, the same registry that your operating system and every major programming language use. Its entries have a stable "Area/City" shape — America/New_York, Europe/Paris, Asia/Kolkata — where the city names the region's most representative location. When you see "convert 3 PM New York to Tokyo", the honest version of that question is: "given a wall-clock reading that a clock in New York shows at some moment, what does a clock in Tokyo show at that same moment?" That is exactly what this tool answers.
Why UTC Is the Reference Point
Every zone is defined as an offset from UTC (Coordinated Universal Time), the modern successor to Greenwich Mean Time. UTC itself is not a zone in the DST sense — it never changes — which makes it the neutral ground where all conversions happen. The math of any time zone conversion has one middle step: first turn the wall time into the absolute instant it represents (in UTC terms), then read that instant back through every target zone's rules. Getting that middle step right is the whole job, and it is the part naive "add the offset" conversions get wrong whenever a DST switch is involved.
How the Tool Works
You provide a wall-clock time — the date and time exactly as a clock in the source zone shows it —
and pick the source zone by searching for its city. The converter first guesses the instant by
treating the wall time as UTC, reads the source zone's true offset at that guess, and corrects;
because offsets change rarely, a couple of passes converge on the exact instant. That instant is
then formatted through every target zone's own rules using the browser's native
Intl support, so daylight saving is handled correctly for both the source and every
destination, including the odd half-hour zones. Results are shown in a stable 24-hour
"YYYY-MM-DD HH:MM:SS" format so they are easy to read, compare, and paste. The table starts as a
curated world clock of the most-used cities; the "Add a City or Zone" search box pulls in any of
the remaining entries, and the × button removes a row you don't need.
Step-by-Step: Scheduling Across the Ocean
A colleague in New York says the call is at 8:30 AM their time on March 15, 2024. Set the date to 2024-03-15, the time to 08:30, and choose New York as the source zone. Because March 15 is after the US DST start, New York is on EDT (UTC-4), so the instant is 12:30 UTC. Reading that instant through the target zones: London shows 12:30 (GMT, before the UK's switch), Paris 13:30 (CET), Dubai 16:30, Tokyo 21:30, and Sydney already on March 15 at 23:30. Try the same call on January 15 and every European reading shifts by an hour while New York moves to EST — a live demonstration of why the conversion depends on the date, not just the zone pair.
A Short History of Time Zones
Time zones did not exist until the 19th century. Before railways, every town set its clocks by the sun, and noon in one town was minutes away from noon in the next — a chaos that was harmless for local life and fatal for train schedules. Britain standardized railway time in the 1840s, and in 1884 the International Meridian Conference in Washington fixed Greenwich as longitude zero and proposed the global system of hourly offsets we still use. The map we see today is the layered result of 140 years of politics: countries joining and leaving daylight saving, borders redrawn across former zones, and the occasional whole-country shift. That history is why "what time is it in X?" is a question with no formula — only a lookup in the rulebook, which is exactly what the IANA database this tool uses stores.
Picking the Right Zone Identifier
When a system asks you for a time zone, give it an IANA identifier, not an abbreviation and not a city nickname. The identifiers follow the Area/City pattern — America/New_York, Europe/Paris, Asia/Kolkata — where Area is a continent or ocean and City is the representative location. Three rules keep you out of trouble: use the canonical spelling exactly (underscores, not spaces, in multi-word cities like America/Los_Angeles); prefer the city over a generic label like "Eastern Time"; and remember that abbreviations (EST, PDT, IST) mean different offsets in different places and seasons. Every entry in this tool's pickers is a valid IANA identifier, so anything you select here is safe to use in code, databases, and operating-system settings.
Full Coverage: Every Zone in the IANA Database
The default table shows roughly sixty of the world's most useful zones, but the search boxes are
backed by the browser's complete copy of the IANA database — every canonical entry the
Intl standard exposes, more than 400 zones in total. That includes the big regional
cities (Buenos Aires, Johannesburg, Vancouver), the famously unusual offsets (Tehran at UTC+3:30,
Kabul at UTC+4:30, Kathmandu at UTC+5:45, Eucla at UTC+8:45, Chatham at UTC+12:45), and even the
historical Etc/GMT+n entries kept for legacy systems. Searching matches both the zone
identifier and the friendly display name, so "Buenos Aires", "America/Argentina", and even a
fragment like "argentina/buenos" all find the same zone. Every result row shows the IANA
identifier it came from, so the exact value you saw here is the value you can paste into code,
a database, or an operating-system setting.
Nothing about this coverage is downloaded: the zone database ships inside the browser itself, and this page merely reads it. That is why the list is always as fresh as the browser's release channel — when a country abolishes daylight saving or renames a zone, the change arrives with the next browser update, with no action on this site's part.
Winter vs Summer Offsets at a Glance
| Zone | Winter | Summer |
|---|---|---|
| UTC | UTC+0 | UTC+0 |
| New York (America/New_York) | UTC-5 (EST) | UTC-4 (EDT) |
| London (Europe/London) | UTC+0 (GMT) | UTC+1 (BST) |
| Paris (Europe/Paris) | UTC+1 (CET) | UTC+2 (CEST) |
| Dubai (Asia/Dubai) | UTC+4 (GST) | UTC+4 (GST) |
| Kolkata (Asia/Kolkata) | UTC+5:30 (IST) | UTC+5:30 (IST) |
| Tokyo (Asia/Tokyo) | UTC+9 (JST) | UTC+9 (JST) |
| Sydney (Australia/Sydney) | UTC+10 (AEST) | UTC+11 (AEDT) |
Zones without a DST column (Dubai, Kolkata, Tokyo) observe no daylight saving at all, so their offsets never change.
Planning Meetings Across Zones
The most common real-world use of a converter is scheduling. The golden rule: always convert to the other person's wall time in their zone, never quote UTC and assume they will do the math — and never quote "9 AM ET" to someone in a different country, because they may read it as their own zone's 9 AM. Check the result twice when the meeting falls near a DST boundary in either location, since the two calendars rarely change on the same night. And when a shared calendar application is involved, it already stores the instant in UTC and renders each attendee's local time — which is the same principle this tool applies, minus the app.
Common Mistakes
Abbreviations Are Ambiguous
"EST" could mean North America's Eastern Standard Time or a time in Australia — the same three letters, different offsets, different DST calendars. "CST" is even worse, meaning five different zones. Always use IANA identifiers or the abbreviation with its zone: EST as in America/New_York.
Adding the Offset Is Not Enough
A hardcoded UTC-5 for New York is correct in January and wrong in July. If you are building your own conversion, you must know the offset at the specific instant — which is what the source-zone rules provide. This tool does that look-up for you.
Offsets Change More Often Than You Think
Countries change DST rules, cancel them, and occasionally shift their whole offset. Data that was correct last year can be wrong this year — one more reason to use the live IANA database instead of a cached table.