Published by Risetop · 9 min read
Scheduling a meeting between New York, London, and Tokyo shouldn't require a spreadsheet — but for many professionals, it often does. Time zones are one of those things that seem simple until you encounter daylight saving time, political border changes, and the baffling reality that not every country has a whole-number offset from UTC. This guide covers how time zones actually work, why they cause so much confusion, and how to convert time accurately every time.
The Earth is divided into 24 time zones, each theoretically spanning 15 degrees of longitude. If this were applied perfectly, every time zone would have a clean offset from UTC (Coordinated Universal Time): UTC+1, UTC+2, and so on. In practice, political boundaries, economic ties, and historical decisions have created a far messier map.
Some countries use half-hour offsets (India is UTC+5:30, Afghanistan is UTC+4:30). Nepal is UTC+5:45. Some Pacific islands are UTC+13 or even UTC+14, which means they're a full day ahead of their geographical neighbors. China, despite spanning five geographical time zones, uses a single time zone (UTC+8) nationwide for political unity. Russia has 11 time zones — the most of any country.
The key concept to understand is that a time zone is not just an offset. A time zone is a region that shares the same rules for determining local time, including daylight saving time transitions. This is why we need named time zones (like "America/New_York") rather than just offsets (like "UTC-5") — offsets change with DST, but the zone's identity doesn't.
UTC (Coordinated Universal Time) is the primary time standard by which the world regulates clocks and time. It's not adjusted for daylight saving time, which makes it the ideal reference point for international scheduling, aviation, computing, and scientific applications.
UTC replaced GMT (Greenwich Mean Time) as the international standard in 1972. While GMT is based on the Earth's rotation (which is slightly irregular), UTC is based on atomic clocks and is occasionally adjusted with leap seconds to stay within 0.9 seconds of the Earth's actual rotation. In everyday usage, UTC and GMT are effectively identical, but technically they're different systems.
When you see a timestamp like 2026-04-15T08:00:00Z, the trailing "Z" indicates UTC (Zulu time). This format, defined by ISO 8601, is the standard for representing timestamps in a timezone-agnostic way. Converting to a local time zone is a display-layer concern — the underlying moment in time is fixed.
The IANA Time Zone Database (often called tz database or tzdata) is the definitive source of time zone rules. It maps geographical regions to their UTC offsets and DST schedules, and it's updated multiple times per year to reflect political changes (countries adopting or abolishing DST, changing their base offset, etc.).
Every major operating system, programming language, and database uses the tz database either directly or indirectly. When your phone automatically adjusts its clock when you cross a border, it's using tz data. When a calendar app correctly shows that a meeting in March in New York is one hour different from the same meeting in January, that's tz data at work.
IANA identifiers follow the pattern Area/Location: America/New_York, Europe/London, Asia/Tokyo, Pacific/Auckland. These are the identifiers you should use in code and in tools — not abbreviations like EST or PST, which are ambiguous and don't account for DST.
Abbreviations like EST, CST, and PST are problematic for several reasons. CST can mean Central Standard Time (UTC-6) in the US, China Standard Time (UTC+8), or Cuba Standard Time (UTC-5). EST is unambiguous in the US context, but it only represents the winter offset — New York switches to EDT (Eastern Daylight Time, UTC-4) in summer, and there's no abbreviation that means "Eastern Time, regardless of season."
For reliable time conversion, always use IANA identifiers. Every modern programming language and most user-facing tools support them. If a tool only accepts offsets or abbreviations, it's probably not handling DST transitions correctly.
Daylight saving time (DST) is the practice of advancing clocks by one hour during warmer months so that evening daylight lasts longer. Roughly 70 countries observe DST in some form, but the rules vary significantly:
| Region | DST Start | DST End | Notes |
|---|---|---|---|
| US/Canada | Second Sunday in March | First Sunday in November | Since 2007 (Energy Policy Act) |
| European Union | Last Sunday in March | Last Sunday in October | All EU members synchronize |
| Australia | First Sunday in October | First Sunday in April | Not all states observe DST |
| Japan/China/India | No DST | Major economies without DST | |
The EU has voted to abolish DST starting in 2027, though the implementation timeline is still being finalized. The US Senate passed the Sunshine Protection Act in 2022 to make DST permanent, but it hasn't been taken up by the House. DST rules are political, and they change — which is another reason to use the tz database rather than hardcoding transition dates.
The practical impact on time conversion is significant. A meeting scheduled for "3 PM Eastern" in January and the same "3 PM Eastern" in July represent different moments in UTC — and different local times in other zones. When scheduling recurring events across DST boundaries, always anchor the time to a specific time zone and let the tz database handle the offset calculations.
The easiest method for one-off conversions is a dedicated time zone converter. Enter a date, time, and source time zone, then select the target zone to see the equivalent local time. Good converters also show the UTC offset for both zones and indicate whether DST is active, which helps you verify the result.
For scheduling across multiple zones, look for a converter that shows several zones simultaneously in a timeline view. This visual approach makes it easy to find overlapping working hours — the windows where it's a reasonable time in all relevant locations.
Always specify the time zone. "Let's meet at 3 PM" is meaningless across time zones. "Let's meet at 3 PM EDT (New York)" or "Let's meet at 3 PM UTC" is unambiguous. Calendar invitations should always include the time zone in the event details.
Anchor to the organizer's zone. When you schedule a recurring meeting, define it in the organizer's time zone and let each participant's calendar convert to their local time. This way, the meeting stays at a consistent local time for the organizer, and participants in other zones can see exactly when it shifts due to DST changes.
Use UTC for servers and APIs. Store all timestamps in UTC and convert to local time only at the display layer. This eliminates a massive class of bugs related to DST transitions, server relocations, and multi-region deployments.
Be aware of "non-existent" and "ambiguous" times. When clocks spring forward (DST start), there's a gap — for example, in the US Eastern zone, 2:00 AM jumps to 3:00 AM. The time 2:30 AM on that date doesn't exist. When clocks fall back (DST end), there's an overlap — 1:00 AM to 2:00 AM occurs twice. If you're building software that handles time, your library should have strategies for resolving these edge cases.
In JavaScript, the Intl API provides built-in time zone support:
// Convert UTC to Tokyo local time
const tokyoTime = new Date('2026-04-15T08:00:00Z')
.toLocaleString('en-US', { timeZone: 'Asia/Tokyo' });
// Get all available time zones
const zones = Intl.supportedValuesOf('timeZone');In Python, the zoneinfo module (standard library since 3.9) handles conversion cleanly:
from datetime import datetime
from zoneinfo import ZoneInfo
utc_time = datetime(2026, 4, 15, 8, 0, tzinfo=ZoneInfo('UTC'))
tokyo_time = utc_time.astimezone(ZoneInfo('Asia/Tokyo'))The pattern is the same across languages: represent the moment in UTC (or with an explicit zone), then convert to the target zone for display. Never do manual offset arithmetic — let the library handle DST transitions and historical changes.
International date line. Crossing the International Date Line eastward subtracts a day; crossing westward adds a day. This means that for parts of the year, there are three different calendar dates in effect simultaneously on Earth — a source of confusion for global systems that need to handle "today" correctly.
Historical time zone data. Time zone rules change frequently. Russia alone has changed its DST policy multiple times since 2010. The tz database tracks all historical changes, which means a library using current tz data can correctly convert dates from the past — but if your application stored offsets instead of zone identifiers, historical conversions will be wrong.
Time zone names vs. UTC offsets in UIs. Showing "UTC+5:30" is technically accurate but unhelpful for users. Showing "India Standard Time" is better. Showing the city name (like "Mumbai") is best for quick recognition. Different contexts call for different levels of detail.
If events are stored with IANA time zone identifiers (not raw offsets), modern calendar systems and libraries automatically apply the correct rules for the date in question. An event created for "2026-03-15 14:00 Asia/Tokyo" will always resolve correctly, even if Japan changes its time zone rules in 2027. This is why storing zone identifiers instead of offsets is critical.
China uses UTC+8 (China Standard Time) nationwide as a matter of national unity and administrative convenience. Geographically, China spans five time zones (UTC+5 to UTC+9), but the single zone policy was established in 1949. Some western regions informally observe their own local time ("Xinjiang Time," UTC+6), but officially, the entire country operates on UTC+8.
Use a world clock or time zone converter that displays multiple zones simultaneously. Look for the overlap where it's between 9 AM and 5 PM (or your team's preferred working hours) in all zones. For teams spanning more than 10 hours of offset, there may be no ideal time — in that case, rotate the meeting time so no single zone is always inconvenienced.
GMT (Greenwich Mean Time) is a time zone based on the Earth's rotation, measured from the Royal Observatory in Greenwich, London. UTC (Coordinated Universal Time) is a time standard based on atomic clocks. GMT can vary slightly from UTC because the Earth's rotation isn't perfectly consistent. For practical purposes like scheduling, the difference is negligible. Use UTC in technical contexts.
No. DST rules are set by individual countries (or even by states within countries). Australia, for example, has states that observe DST and states that don't, despite being in the same time zone area. The US, Canada, and Mexico all have different DST schedules despite sharing time zones. Always use IANA identifiers that encode these differences.
Always store timestamps in UTC. Use a TIMESTAMP WITH TIME ZONE column type (or equivalent) if your database supports it, which records the UTC value and the source time zone. For display, convert from UTC to the user's local time zone at the application layer. Never store local time without an accompanying zone identifier.
Try our World Clock & Time Zone Converter — see current time across multiple zones and convert times instantly.