Guide

Time zone conversion: why it fails and how to get it right.

"3 PM EST" — simple, right? Wrong. In January that's New York at UTC−5; in July it's EDT at UTC−4. And "CST" means Central US, China, or Cuba depending on who's talking. One wrong assumption and someone dials in an hour early — or the day before. Here's how to convert correctly every time.

Updated November 9, 2026 · Reviewed by The Vibing Dev.

The abbreviation trap

Time zone abbreviations are not unique and not stable:

Rule: Never use abbreviations for scheduling. Use city names or IANA zones — "3 PM Chicago" can never be misread. Our IANA database guide explains the system behind them.

What is an IANA time zone?

The IANA Time Zone Database (tz database) is the global standard. Each zone has a unique identifier:

• America/New_York — Eastern US (handles EST/EDT automatically)
• Europe/London — UK (handles GMT/BST automatically)
• Asia/Kolkata — India (UTC+5:30, no DST)
• Australia/Sydney — NSW (handles AEST/AEDT)
• America/Phoenix — Arizona (no DST, always UTC-7)

The planner lets you search any IANA zone directly. Type "Kathmandu" → gets Asia/Kathmandu (UTC+5:45). Type "Anchorage" → gets America/Anchorage (UTC-9/-8).

UTC offsets: useful but incomplete

Fixed offsets (UTC-5, UTC+8, UTC+5:30) work for:

• Regions without DST
• Quick mental math
• Systems that don't support IANA

They fail for:

• Any region with DST (offset changes twice/year)
• Historical/future dates (offset may have been different)
• Regions that changed offset (e.g., Samoa skipped a day in 2011)

The planner supports both: search "UTC+5:30" for fixed offset, or "Kolkata" for IANA.

Common conversion mistakes

1. Using current offset for future dates — \"It's UTC-4 now, so July 15 is UTC-4\" → wrong if DST hasn't started yet
2. Ignoring day boundaries — 10 PM ET = 3 AM GMT next day. 11 PM ET = 4 AM GMT. The date shifts.
3. Assuming symmetric DST — US and EU switch different weeks. The gap changes 2×/year.
4. Using \"GMT\" as a zone — GMT = UTC+0 always. London = GMT in winter, BST (UTC+1) in summer.
5. Trusting Google for scheduling — \"3 PM EST in PST\" works for now, not for \"next Tuesday\"

How to convert correctly: the workflow

1. Identify the IANA zone for each location (search city name in planner)
2. Specify the exact date — DST depends on the date
3. Use a DST-aware tool — This planner, or date -d 'TZ=\"America/New_York\" 15:00' \"+%Z %z\" in terminal
4. Verify both directions — Convert A→B and B→A
5. Share as UTC or .ics — Never share "3 PM EST"; share "2026-11-14T19:00:00Z" or an .ics file. See practice #6 in our scheduling best practices.

Fractional offsets you'll encounter

Why this planner gets it right

• Browser-native Intl API — Same IANA database as Chrome, Firefox, Safari, Node.js
• Search by city, zone, or offset — \"Tokyo\", \"Asia/Tokyo\", or \"UTC+9\" all work
• Date-aware — Pick the meeting date; DST calculated for that day
• Cross-day indicators — +1d / -1d badges show when a meeting spans midnight
• Shareable state — Link encodes zones, hours, and date — recipient sees correct times