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" added to keep it aligned with 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.
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.
Common Time Zone Offsets
| Region | Standard Time | DST (when applicable) |
|---|---|---|
| London | UTC+0 (GMT) | UTC+1 (BST) |
| Paris, Berlin, Madrid | UTC+1 (CET) | UTC+2 (CEST) |
| New York | UTC−5 (EST) | UTC−4 (EDT) |
| Chicago | UTC−6 (CST) | UTC−5 (CDT) |
| Los Angeles | UTC−8 (PST) | UTC−7 (PDT) |
| Mexico City | UTC−6 | UTC−5 (most places) |
| São Paulo | UTC−3 | (DST abolished 2019) |
| Tokyo | UTC+9 | (no DST) |
| Sydney | UTC+10 (AEST) | UTC+11 (AEDT) |
| Mumbai, New Delhi | UTC+5:30 | (no DST) |
| Beijing, Shanghai | UTC+8 | (no DST) |
| Dubai | UTC+4 | (no DST) |
| Lagos | UTC+1 | (no DST) |
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
- Russia (abolished DST in 2011)
- Iceland, Belarus, Turkey (year-round summer time)
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 for the two weeks in March when Europe hasn't sprung forward yet and the U.S. has, the difference shrinks to 4 hours. The same anomaly happens in late October when Europe falls back first.
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.
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. Even within the EU, the rules are uniform; in the U.S., Arizona and Hawaii opt out; in Russia, no DST at all.
Confusing UTC offset with time zone identity. Two zones can share an offset but have different DST rules. Madrid and Stockholm are both UTC+1 standard time, but they handle DST in the same way; Argentina (UTC−3) and Brazil (UTC−3) don't.
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. The World Clock shows the current time across multiple zones simultaneously. For meeting planning, the Meeting Time Planner finds overlap windows across participants, and the Time Difference Calculator computes the exact gap between any two locations.
Related Articles
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.