Time Zones & UTC, Explained

Why time zones exist

For most of history, every town kept its own local time, set by the sun — noon was simply when the sun was highest overhead. That was fine until railways and the telegraph made it possible to travel and communicate faster than the sun appears to move, at which point thousands of slightly different local times became chaos. The solution, adopted in the late nineteenth century, was to divide the world into broad time zones, each keeping a single standard time, offset from a common reference by a whole (or occasionally half) number of hours.

That common reference is now Coordinated Universal Time, or UTC. Every zone in the world is described by its offset from UTC: New York in winter is UTC−5, India is UTC+5:30, Japan is UTC+9. Convert any two local times to UTC and the comparison becomes trivial. TheTime Zone Converterdoes this for you, showing one moment in as many cities as you like.

UTC, GMT and offsets

People use "UTC" and "GMT" almost interchangeably, and for everyday scheduling that is harmless. Strictly, GMT (Greenwich Mean Time) is a time zone, while UTC is a time standard maintained by atomic clocks. They line up in the London winter, but London itself moves to UTC+1 in summer, so GMT and London time are not always the same thing. When precision matters — timestamps in software, flight schedules, international contracts — UTC is the unambiguous reference.

An offset like UTC+5:30 means that zone's clocks read 5 hours and 30 minutes ahead of UTC. A few zones use 30- or 45-minute offsets (India, parts of Australia, Nepal), which is why "just add whole hours" mental math sometimes fails. The converter always shows the exact offset next to each city so there is never any doubt.

Daylight saving: the thing that breaks schedules

Roughly a third of the world shifts its clocks forward an hour in spring and back an hour in autumn to make better use of daylight. This is daylight saving time (DST), and it is the single biggest source of scheduling errors. The problem is not DST itself but that regions change on different dates — and some do not change at all.

Consider New York and London. For most of the year they are 5 hours apart. But the United States "springs forward" in mid-March while Europe waits until the end of March, so for about two weeks each spring the gap is only 4 hours. In autumn the reverse happens. A recurring 3 p.m. London call that a New Yorker joins at 10 a.m. will, for those few weeks, actually be at 11 a.m. — an hour "wrong" for anyone who assumed the offset was fixed. Places like most of India, China, Japan and Arizona never observe DST, adding yet another layer to track.

Note Sydney: because it is in the southern hemisphere, its summer is the northern winter, so it "springs forward" when Europe and North America are falling back. This is why a fixed offset between, say, London and Sydney is wrong for large parts of the year. The only reliable approach is to convert using the actual date of the event — which is exactly what a converter backed by the world time-zone database does automatically.

The IANA time-zone database

Behind every reliable converter is the IANA time-zone database (also called the tz or zoneinfo database), a continuously updated record of every region's offset and daylight-saving rules, past and future. Zones are named by a representative city — America/New_York, Europe/London, Asia/Kolkata — rather than by offset, precisely because the offset changes with the season and occasionally with the law. When a government changes its DST policy, the database is updated and browsers pick it up, so conversions stay correct. This tool uses your browser's built-in copy of that data.

How to schedule across time zones without mistakes

• Convert with the real date. Never assume a fixed offset — a call three weeks out may straddle a DST change.
• Anchor to UTC for records. When writing a time down or storing it, note the UTC time (or include the offset) so it is unambiguous later.
• Name the city, not just the offset. "3 p.m. New York time" survives DST; "3 p.m. EST" is wrong for half the year (it is EDT in summer).
• Find the overlap. For a team spread across zones, look for the window where everyone is within working hours — sometimes it is narrow, and knowing that early prevents a 6 a.m. call.
• Watch the date line. A morning meeting in the US can fall on the following day in Asia; always check the weekday, not just the clock.

A worked example

You are in London and want to schedule a 30-minute call with colleagues in New York, Bangalore and Tokyo for next Tuesday. You propose 12:00 noon London time. Converting that single instant: New York reads 7:00 a.m. (a stretch, but workable), Bangalore reads 4:30 p.m. (comfortable), and Tokyo reads 8:00 p.m. (late but acceptable). Shift the call to 09:00 London and New York becomes 4:00 a.m. — clearly too early. Push to 14:00 London and Tokyo becomes 10:00 p.m. The noon slot is the best compromise, and you could confirm it instantly by adding all four cities to theTime Zone Converterand sliding the time until every local time sits in range.

From sundials to atomic clocks

The whole apparatus of time zones is surprisingly recent. For most of history, every town set its clocks by the sun, so noon in one city was a few minutes different from noon in the next. That was fine until the railways arrived: trains crossing the country on a fixed schedule made thousands of slightly different local times unworkable and dangerous. Britain's railways adopted a single standard time in the 1840s, and in 1884 an international conference in Washington established Greenwich as the prime meridian and divided the globe into standard zones.

The reference itself has since become more precise. UTC is kept by a global network of atomic clocks, accurate to billionths of a second, and it occasionally has a leap second inserted to stay aligned with the Earth's slightly irregular rotation. You never need to think about leap seconds in daily life, but they are a reminder that keeping the world's clocks in sync is an active, ongoing engineering effort — and the reason a converter that leans on the maintained time-zone database is so much safer than mental arithmetic.

The strange edge cases

Time zones are set by governments, not physics, which makes them wonderfully irregular. A converter backed by the real time-zone database handles all of these automatically; trying to do them in your head is where mistakes happen.

These are not trivia — they are exactly the cases where "just add the hours" fails. India's half-hour offset breaks whole-hour mental maths; China's single zone means the sun and the clock disagree by hours in the west of the country; and southern-hemisphere DST means the gap between London and Sydney changes by two hours across the year, not one.

UTC in software: store it right

If you build anything that records time — a booking system, a log, a chat app — there is one rule that eliminates almost every timezone bug: store time in UTC, and convert to local only when you display it. Save a bare local time like "3 p.m." and it is meaningless the moment it crosses a timezone or a daylight-saving boundary; save the UTC instant (or a full ISO 8601 string with an offset) and it is unambiguous forever, sortable, and convertible for any viewer.

The corollary is to never do timezone maths by hand in code. Use a library backed by the same IANA database this tool relies on, and let it apply the correct historical and future rules for each zone and date. Governments change their DST policies with little notice; a maintained database absorbs those changes so your software stays correct, while hard-coded offsets silently rot.

Tactics for distributed teams

• Find the golden overlap. Map everyone's working hours to one zone and look for the window where they intersect; protect it for anything that needs live discussion.
• Rotate the pain. If no comfortable overlap exists, alternate which region takes the awkward hour so it is not always the same people.
• Default to async. When overlap is tiny, write things down instead of meeting, and reserve live time for what truly needs it.
• Always label the zone. Send invites in each recipient's local time, and in writing name the city, not an abbreviation.

Reading and writing an offset correctly

A UTC offset looks simple but hides a common slip: the sign points the "wrong" way from what many people expect. UTC+9 means Tokyo is nine hours ahead of UTC — when it is noon in Greenwich, it is 9 p.m. in Tokyo. UTC−5 means New York is five hours behind — noon in Greenwich is 7 a.m. in New York. To convert a UTC time to a local one, you add the offset; to go the other way, you subtract it. Getting the direction backwards is the single most frequent manual-conversion error, which is exactly why the converter shows each city's offset right next to its local time so there is nothing to compute in your head.

Abbreviations make it worse, not better. "EST" and "EDT" are both "Eastern" but differ by an hour, "IST" means Indian Standard Time to some and Irish or Israel Standard Time to others, and "CST" is claimed by at least three different zones around the world. Because these letter codes are ambiguous and change with the season, the safe way to write a time is either as a numeric offset (UTC+5:30) or by naming the city (Kolkata time), never by a bare abbreviation.

Why professionals use 24-hour time and ISO dates

People who schedule across borders for a living tend to converge on two conventions, and it is worth adopting them. The first is the 24-hour clock. "3:00" is ambiguous — a.m. or p.m.? — and that ambiguity has caused countless missed calls; "15:00" cannot be misread. The second is ISO 8601 for written dates and times: 2026-07-28T15:00:00Z. It puts the largest unit first, uses fixed widths, and the trailing Z unambiguously marks UTC.

The everyday benefit shows up in the date field: is "04/07" the fourth of July or the seventh of April? It depends entirely on the reader's country, and international teams get this wrong constantly. ISO's 2026-07-04 is read the same way by everyone, and as a bonus it sorts correctly as plain text. Pairing a UTC-anchored ISO timestamp for the record with a clearly-labelled local time for each participant removes almost every avenue for a scheduling mix-up — and the converter gives you both, from a single chosen moment.

Travel, deadlines and "arrives the next day"

Two everyday situations catch people out even once they have the basics. The first is travel: a long-haul flight that leaves in the evening and "arrives tomorrow morning" often takes far fewer hours in the air than the clock suggests, because you are also crossing time zones — and flying east or west changes whether you gain or lose hours on paper. The second is the deadline that lands on a different day: "submit by 5 p.m. Friday, US Pacific time" is already Saturday in much of Asia, so a colleague there must check the weekday, not just the clock, to avoid missing it by a full day. In both cases the safe move is identical to everything else in this guide — convert the one true instant into each relevant local time, and read off the day as well as the hour rather than trusting a rough mental estimate.

Time zones feel intimidating because the rules are irregular and change with politics and the seasons. But you do not need to memorise any of it. Convert one moment to every city that matters, using the actual date so daylight saving is handled for you, and the right meeting time — or the correct local time for a deadline — becomes obvious at a glance.