How Time Zones and Time Differences Work

Time zones look like a clean longitude problem until you actually try to schedule a meeting across a few of them. India is offset by 30 minutes from the nearest "whole" zones. China spans five geographic zones but uses one. Daylight saving time shifts twice a year in some places, year-round in others, and not at all in many. The math of "what time is it there?" is more political than astronomical.

Key Takeaways

• UTC (Coordinated Universal Time) is the global time reference; all time zones are expressed as offsets from UTC.
• Most time zones are whole hours from UTC; a few are 30 or 45 minutes off.
• Daylight Saving Time (DST) shifts clocks forward in spring and back in fall, but only in some regions.
• GMT and UTC are nearly identical for practical purposes.
• A "time difference" between two cities depends on the date, because DST may apply differently.

What UTC Actually Is

Coordinated Universal Time (UTC) is the global standard for civil time. It is based on atomic clocks, with occasional "leap seconds" inserted to keep it within a second of the Earth's rotation. Every other time zone is expressed as an offset from UTC: UTC+1, UTC−5, UTC+5:30, and so on.

Leap seconds are on the way out. The General Conference on Weights and Measures agreed in 2022, in Resolution 4, to increase the maximum tolerated difference between UTC and Earth-rotation time by or before 2035, which removes the need for the leap-second insertions that have periodically broken timekeeping software. Until then, UTC can still gain an occasional extra second, and systems that assume every minute has exactly 60 seconds are still making an assumption.

UTC does not observe daylight saving time. It is the same year-round. This is one reason it's used in aviation, computing, and international coordination: it never shifts.

GMT (Greenwich Mean Time) is closely related. For practical purposes UTC and GMT are interchangeable; technically GMT is a time zone (the UK's winter time), while UTC is a time standard. Most people use the terms loosely.

How Time Zones Are Defined

In theory, the Earth's 360 degrees of longitude divide neatly into 24 zones of 15 degrees each. In practice, time zones follow political and economic boundaries:

• China uses one time zone (UTC+8) across all of its territory, even though the country geographically spans five zones.
• India uses UTC+5:30, a 30-minute offset that has no neighbors at the same time.
• Nepal uses UTC+5:45, a 45-minute offset, unique to the country.
• France uses UTC+1 despite being geographically aligned with UTC.
• Newfoundland (Canada) uses UTC−3:30.

The full list of named time zones (Europe/London, America/New_York, Asia/Kolkata, etc.) is maintained by the IANA Time Zone Database, which most computers use under the hood.

Named Zones and Fixed Offsets Are Not the Same Thing

The list of named time zones is maintained as the IANA Time Zone Database, often called tzdb or the Olson database. Nearly every operating system, programming language and database gets its zone rules from it, and it is updated several times a year as governments change their minds.

Identifiers look like America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney. The convention is Area/Location, where the location is a representative city rather than a country, because countries split and merge and cities mostly do not. A few identifiers are deliberately not cities (Etc/UTC, UTC), and older aliases such as US/Eastern still resolve but are kept only for compatibility.

The distinction that matters in practice:

• A fixed offset is a number, like +05:30 or −04:00. It describes one moment and carries no rules. It cannot tell you what the offset will be next July.
• A named zone is a rule set covering the entire history and current law of a place. America/New_York knows it was UTC−5 in January 2026, UTC−4 in July 2026, and it knows when the switch happens.

This is why "EST" and "PST" are poor choices in code. They are display abbreviations, they are ambiguous across the world (CST is Central Standard Time in North America, China Standard Time and Cuba Standard Time depending on who is writing), and they pin you to one half of the year. A future event needs a named zone. A past instant that has already happened can be stored as UTC.

The practical rule: store a past instant as UTC, store a future local commitment as local time plus a named zone. "The board meets at 09:00 on 3 March in Europe/London" survives a change to the UK's DST law. "The board meets at 09:00 UTC" does not, because the intent was the local morning, not the UTC value.

Common Time Zone Offsets

Daylight Saving Time

DST is the practice of moving clocks forward in spring (typically by 1 hour) and back in fall. The intent is to align waking hours with daylight, reducing energy use.

Where DST applies:

• Most of Europe (last Sunday of March to last Sunday of October)
• Most of the U.S. and Canada (second Sunday of March to first Sunday of November)
• Parts of Australia, New Zealand
• Some other isolated regions

Where DST does not apply:

• Most of Asia and Africa
• Hawaii and most of Arizona (within the U.S.)
• Most of South America; Chile is the notable exception that still changes clocks
• Most of Mexico, which ended nationwide seasonal clock changes in 2022; municipalities on the U.S. border are the exception
• Russia (abolished DST in 2011)
• Belarus and Turkey, which stopped changing clocks and stayed on UTC+3 year-round
• Iceland, which has sat on UTC+0 all year since 1968 and never shifts

DST creates two "transition windows" each year where the offset changes. During these windows, the time difference between two cities can be temporarily different from normal.

Example: New York and London are normally 5 hours apart (EST/GMT) in January. They are also 5 hours apart in July (EDT/BST, both at +1 from standard). But the two regions do not switch on the same day, so there are windows each year when the gap is 4 hours instead of 5.

In 2026 the U.S. springs forward on 8 March and the EU and UK on 29 March, giving three weeks where New York is only 4 hours behind London. In autumn the order reverses: the UK falls back on 25 October and the U.S. on 1 November, producing another 4-hour week. The dates move every year because both rules are "the nth Sunday of a month," not a fixed date, so a recurring 3 p.m. London call lands at a different New York hour for a few weeks each spring and autumn.

Local Times That Happen Twice, and Local Times That Never Happen

DST transitions do something more awkward than shifting a number: they break the assumption that every local time exists exactly once. Both failure modes are worth knowing by name, because they produce bugs that only appear twice a year.

Skipped times (the spring gap). In America/New_York, at 02:00 on 8 March 2026 the clock jumps straight to 03:00. Local times from 02:00:00 to 02:59:59 do not occur that day. A daily 02:30 alarm has no valid moment to fire; a form that accepts "02:30 on 8 March" is accepting a time that does not exist. Systems handle this differently: some shift forward to 03:30, some shift back to 01:30, some throw an error. None of them are wrong, which is exactly the problem when two systems disagree.

Repeated times (the autumn overlap). At 02:00 on 1 November 2026 the same clock goes back to 01:00. Local times from 01:00:00 to 01:59:59 occur twice: once at UTC−4 and again, an hour later in real time, at UTC−5. "01:30 on 1 November" identifies two different instants, 60 minutes apart. Logs sorted by local timestamp will interleave incorrectly, and a job scheduled for 01:30 may run twice.

A day is not always 24 hours. On 8 March 2026, midnight to midnight in New York is 23 hours long; on 1 November it is 25. Adding 86,400 seconds to a timestamp and calling it "tomorrow at the same time" gives the wrong local clock reading on those two days. Calendar arithmetic ("add one day") and elapsed-time arithmetic ("add 24 hours") are different operations, and libraries expose them separately for this reason.

The defensive habits are small. Do date arithmetic in the local zone with a real date library, not by adding seconds. Convert to UTC only after the local arithmetic is done. When a local time is ambiguous, decide explicitly which of the two instants you mean rather than letting a default choose. And when a local time is invalid, reject it at the input rather than silently relocating it.

Calculating Time Differences

The basic formula:

Time Difference = Source UTC Offset − Target UTC Offset

A positive result means the target is ahead; a negative result means the target is behind.

Example: Meeting between London (UTC+1 in summer) and Mumbai (UTC+5:30 year-round).

Mumbai offset: +5:30 London offset: +1:00 Difference: +5:30 − +1:00 = +4:30

If it's 9:00 AM in London, it's 1:30 PM in Mumbai.

Example: New York (UTC−4 EDT in summer) and Tokyo (UTC+9 year-round).

Tokyo offset: +9 New York offset: −4 Difference: +9 − (−4) = +13

If it's 10:00 AM in New York, it's 11:00 PM in Tokyo (same day). If it's 2:00 PM in New York, it's 3:00 AM the next day in Tokyo.

Always remember to handle date rollovers when the time difference pushes past midnight in either direction.

Worked Example: Scheduling a Three-Way Meeting

A team in San Francisco (UTC−7 PDT in May), London (UTC+1 BST), and Singapore (UTC+8 no DST) needs to find a meeting time.

Let's check 9:00 AM Pacific:

• San Francisco: 9:00 AM
• London: 9 + (1 − (−7)) = 9 + 8 = 5:00 PM
• Singapore: 9 + (8 − (−7)) = 9 + 15 = 12:00 AM (midnight) ← bad

Try 4:00 PM Pacific (a late afternoon meeting):

• San Francisco: 4:00 PM
• London: 4 + 8 = 12:00 AM (midnight) ← bad

The reality: a true three-way live meeting across San Francisco / London / Singapore has no good time. One of the three will be at a difficult hour. Asynchronous tools are usually a better answer for distributed teams across all three zones.

The Date Line

The International Date Line runs approximately along 180° longitude. Crossing it changes the calendar date:

• Going west to east (e.g., Tokyo to Hawaii): subtract a day.
• Going east to west (e.g., Los Angeles to Tokyo): add a day.

This is why a flight from LA to Tokyo that takes 11 hours leaves Monday and arrives Tuesday afternoon: you crossed the date line on the way.

Some islands (Samoa, Kiribati) have specifically chosen which side of the date line to be on for trade reasons, sometimes creating unusual jumps in the line's path.

UTC in Computing

Most modern software stores times in UTC internally and converts to local time only for display. This is the right pattern:

• Storage: UTC timestamps (e.g., 2026-05-11T14:30:00Z) are unambiguous and never need to be re-interpreted.
• Computation: Time arithmetic in UTC is straightforward, with no DST surprises.
• Display: Convert to the user's local time zone when rendering.

A common bug: storing local times without time zone information. When DST shifts or the user travels, ambiguities arise. Always store with explicit time zone or UTC.

Writing Timestamps Down Correctly

There is a standard for this, and using it removes a whole category of parsing arguments.

RFC 3339, "Date and Time on the Internet: Timestamps", is the profile of ISO 8601 that most internet protocols and APIs actually use. It fixes the shape as YYYY-MM-DDTHH:MM:SS followed by either Z or a numeric offset such as +05:30. Z means an offset of 00:00, spoken "Zulu". The specification also defines -00:00 as a distinct signal meaning the instant in UTC is known but the local offset is not, which is useful and almost universally ignored.

RFC 9557, "Date and Time on the Internet: Timestamps with Additional Information", extends that format so a timestamp can also carry its named zone in brackets:

1996-12-19T16:39:57-08:00[America/Los_Angeles]

That single string records three separate things: the instant, the offset that applied at the instant, and the zone whose rules produced it. Keeping the zone alongside the offset is what lets a later reader answer "what would this be an hour after the DST switch?" instead of only "what was the offset that day?"

Two consequences follow for anyone designing a schema. An offset column is not a substitute for a zone column, and a zone column is not a substitute for the stored instant. Events that recur in local time need both the local wall time and the zone identifier; an instant that has already happened needs only the UTC timestamp.

Common Mistakes

Forgetting DST when scheduling. "9 AM their time" can mean different things at different points in the year.

Treating GMT and BST as the same. GMT is UTC+0 year-round; BST (British Summer Time) is UTC+1 from spring to autumn.

Using non-IANA time zone names. "EST" and "PST" are ambiguous; they could mean standard time year-round (Arizona) or only in winter (most of the U.S.). Use IANA names like "America/New_York" in code.

Date arithmetic without time zones. Computing "tomorrow at this time" can give wrong results during DST transitions if the math is done in local time.

Assuming all countries observe DST identically. The EU switches on the last Sunday of March and October; the U.S. and Canada use the second Sunday of March and first Sunday of November, and Arizona and Hawaii opt out entirely. Southern hemisphere zones that observe DST shift in the opposite months. "Everyone changes clocks around the same weekend" is wrong often enough to break recurring meetings twice a year.

Confusing UTC offset with time zone identity. An offset is a value at a moment; a time zone is a set of rules over time. Phoenix and Denver are both UTC−7 in January, but only Denver moves to UTC−6 in summer, so storing "UTC−7" instead of America/Phoenix or America/Denver loses the information you need to convert any other date. Two places sharing an offset today may not share one next month.

Practical Scenarios

Scenario 1: Booking an international flight. Departure is shown in local time at the origin; arrival is shown in local time at the destination. The actual flight duration is the difference accounting for time zones, not the clock difference.

Scenario 2: Joining a live webinar. Webinar starts at "3 PM ET", which is Eastern Time. That's EDT in summer and EST in winter. If the event is in March, check whether DST has started.

Scenario 3: Daily standup across continents. Team in NYC, Bangalore, and Berlin. NYC 9 AM = Bangalore 6:30 PM (working day ending) = Berlin 3 PM. Reasonable for all three. NYC 9 AM in winter (EST) = Bangalore 7:30 PM (later); same time of day in NYC but different elsewhere because of NYC's DST.

Scenario 4: Anniversary or appointment reminders. A birthday on May 15 should fire on the user's local May 15, not on some fixed UTC moment. App developers need to handle this carefully.

FAQ

What is UTC? Coordinated Universal Time: the global time reference, based on atomic clocks. All time zones are expressed as offsets from UTC.

Are UTC and GMT the same? For practical purposes, yes. Technically GMT is a time zone (UK winter time) and UTC is a time standard, but they have the same offset and most people use the terms interchangeably.

How do I calculate time difference between two cities? Look up each city's UTC offset for the current date (accounting for DST), then subtract. The result tells you how many hours one city is ahead or behind the other.

Why does India have a half-hour offset? For historical and political reasons. India chose UTC+5:30 in 1947 as a single national time zone, splitting the difference between the geographic zones the country spans.

Does daylight saving time happen everywhere? No. Most of Europe, the U.S., Canada, and parts of Australia and New Zealand observe DST. Most of Asia, Africa, and South America do not.

How does DST affect time zone calculations? During DST, the affected zones' offsets shift by 1 hour (typically). The time difference between two cities can change temporarily if one observes DST and the other doesn't, or if their transition dates differ.

Why do programmers store times in UTC? Because UTC doesn't have DST or time zone ambiguities. Storing in UTC and converting for display avoids most date-time bugs. Local time storage is a frequent source of errors.

Related Tools

The Time Zone Converter handles conversions between any two cities with DST awareness, shows the exact time gap, and helps you test possible meeting times.

Related Articles

• Metric vs Imperial Units
• Word Count, Character Count, and Readability

Sources

• IANA Time Zone Database - the canonical source of zone identifiers and their historical rules, updated as governments change the law.
• RFC 3339: Date and Time on the Internet: Timestamps - the interchange format used by most internet protocols, including the meaning of the Z and -00:00 suffixes.
• RFC 9557: Date and Time on the Internet: Timestamps with Additional Information - the extension that attaches a named time zone to an RFC 3339 timestamp.
• CGPM Resolution 4 (2022) on the use and future development of UTC - the international decision to increase the tolerated UT1 minus UTC difference by or before 2035.

Final Thoughts

Time zones are one of the few areas where reality is messier than its abstraction. The clean idea (divide the world into 24 zones based on longitude) runs straight into political borders, historical decisions, and the twice-yearly chaos of daylight saving time. The practical advice is simple: always check the specific date when scheduling, use IANA time zone identifiers in code, store times in UTC, and use a converter whenever you're not sure. The math is straightforward; the edge cases are where the complexity lives.