Timezone Converter & World Clock

A timezone converterturns a moment in one zone into the equivalent reading in any other zone — “9:00 AM in Mumbai is 11:30 PM the previous day in Los Angeles.” The developer tool above does the same thing with three useful extras: live world clocks, side-by-side comparison across an arbitrary list of cities, and an overlap chart that shows when everyone is at their desk simultaneously.

Under the hood, every conversion is a translation between an instant (an absolute moment in time, usually represented as a Unix timestamp or UTC ISO string) and a wall-clock reading (the date and time someone would observe on a clock in a particular city). A timezone converter is a function that takes one of those and gives you the other.

Timezone bugs are a top-five source of production incidents in any system that schedules, logs, or bills. The reasons are consistent across stacks:

• Cron jobs run twice or skip a daywhen daylight saving rolls over. UTC-anchored schedules avoid this; local-time schedules don't.
• Webhook payloads arrive with naive timestamps (no “Z”, no offset). The receiver guesses, picks its own zone, and quietly off-sets your data by 5–13 hours.
• Dashboards aggregate across zones— a “daily active users” chart that bins on local calendar days disagrees with one that bins on UTC days, and both feel right depending on what you're trying to show.
• OAuth and JWT lifetimes compare server time against exp. If one server's clock is in local time and another's in UTC, tokens look invalid intermittently.

The timezone converter above is a thinking toolfor these problems — paste a Unix timestamp, see the same instant in your staging server, your prod region, and your customer's region in one glance.

Distributed teams almost always discover the same hierarchy of scheduling pain. As a team grows from one timezone to many, the time-of-day budget for “everyone is awake at once” shrinks fast.

• Two zones inside the same continent — usually 5+ hours of overlap. Easy.
• USA + India — typically 1.5 hours of overlap between US Eastern late afternoon and India late evening. Most standups land here.
• USA + Australia — close to zero overlap with standard 9-to-5 hours. Almost every recurring meeting has someone joining outside their working window.
• Three or more zones spread globally — pick one shared synchronous slot per week and structure everything else asynchronously.

The overlap chart in the tool above is built for exactly this: add the zones, set each member's working hours, and the highlighted band shows the longest contiguous block where everyone is at work. If no such block exists, the band falls back to the partial overlap that covers the most people.

A UTC offsetis the signed number of hours and minutes between a city's local time and Coordinated Universal Time. New York in winter is UTC−05:00 — so 13:00 UTC is 08:00 in New York. Mumbai is always UTC+05:30 — 30-minute offsets are real and not as rare as you'd think (Iran, Afghanistan, Newfoundland, Nepal at +05:45, Chatham Islands at +12:45).

Crucially, an offset is nota timezone. New York's timezone is America/New_York — a rule set that produces an offset of −05:00 for half the year and −04:00 for the other half. Storing “EST” or “−05:00” in your database is a lossy choice that breaks the moment a daylight-saving boundary crosses. Store an IANA zone name instead, and let the runtime compute the offset on demand.

The reference list of all canonical names is the IANA Time Zone Database (often called “tzdata” or “zoneinfo”), updated several times a year. Modern browsers, Node.js, Go's time package, and Python's zoneinfo module ship a copy or read from the OS — there's no need to hand-maintain a list.

Daylight saving time (DST) is the source of nearly every “recurring meeting moved by an hour without warning” incident on a remote team. Three things make it sneaky:

1. Different countries shift on different dates. The US moves DST on the second Sunday of March; the EU on the last Sunday. Between those Sundays, what was a 5-hour gap between New York and London becomes a 4-hour gap.
2. Many countries don't shift at all.India, Japan, China, most of Africa, Arizona — these zones stay put while the US and Europe oscillate around them. So an India-NYC team has a different overlap window summer vs winter even though India's clock never moved.
3. The southern hemisphere shifts in the opposite direction. When London springs forward in March, Sydney falls back in April. Australia–UK overlap inverts twice a year.

The tool above tags any zone currently inside its DST window with a small DST badge so you can spot at a glance which clocks have drifted relative to their winter offset.

• Store IANA zone names, not offsets. A user record should carry timezone: "America/New_York", not tz_offset: "-05:00". The runtime computes the correct offset including DST.
• Persist instants in UTC. Every database timestamp column should be UTC. Convert to local for display and only at display.
• Schedule recurring events in the host's zone. If a standup is “9:00 AM Berlin every weekday”, store that, not 7:00 UTC. The two diverge by an hour twice a year.
• Rotate the off-hours load.If a fully overlapping window doesn't exist, alternate weekly so the cost of joining outside working hours doesn't fall on the same people every time.
• Default async, sync deliberately. Treat synchronous meeting time as the scarce resource. The team that communicates well asynchronously needs an overlap window only for the conversations that genuinely benefit from real-time back-and-forth.

Indian Standard Time (IST) is UTC+05:30 year-round — India does not observe daylight saving.

Pacific Standard Time (PST) is UTC−08:00 in winter; Pacific Daylight Time (PDT) is UTC−07:00 in summer. The IANA zone is America/Los_Angeles and the runtime picks PST or PDT automatically.

That gives a difference of 13 hours 30 minutes in winter (IST is ahead) and 12 hours 30 minutes in summer. The classic SaaS overlap window is roughly 8:30 PM India / 8:00 AM Pacific in summer — the slot most India ↔ US standups settle on.

Watch out for the IST collision: Israel Standard Time is also abbreviated IST. When in doubt write the offset (UTC+05:30) or the IANA name.

Eastern Standard Time (EST) is UTC−05:00; Eastern Daylight Time (EDT) is UTC−04:00. The IANA zone is America/New_York and covers New York, Boston, Atlanta, Toronto, and most of the US eastern seaboard.

Convention in tooling: developer-facing systems usually log in UTC because it never shifts and never argues with cron schedules. Customer-facing systems usually display in EST/EDT (or whichever zone the user is in) because that's what reads naturally on a calendar invite.

A useful mental model: UTC is for storage, EST/EDT is for presentation. Convert at the boundary between the two — typically the rendering layer of your front end — and never inside business logic.

• Treating “Z” as optional. ISO-8601 strings without a trailing Z or +HH:MM are local-time and ambiguous. Always serialise UTC instants as 2024-08-21T13:45:00Z.
• Mixing seconds and milliseconds. Unix epoch in POSIX is in seconds. Date.now() in JavaScript is in milliseconds. The converter above auto-detects 13-digit values as milliseconds, but production code should be explicit.
• Storing the abbreviation. “CST” means Central Standard Time, China Standard Time, or Cuba Standard Time depending on context. Store the IANA name; the abbreviation is for humans.
• Recurring events at 1:30 AM local.When the clock falls back, that wall-clock time happens twice. When it springs forward, it doesn't happen at all. Pick a less ambiguous slot or pin to UTC.
• Browser-detected timezone for the source of truth. Intl.DateTimeFormat().resolvedOptions().timeZone is great for display. It shouldn't be the only thing recorded against a user — they may travel, or override their system tz.

JavaScript / TypeScript

// Format a UTC instant in any IANA timezone
const fmt = new Intl.DateTimeFormat("en-US", {
  timeZone: "Asia/Kolkata",
  dateStyle: "medium",
  timeStyle: "short",
});
fmt.format(new Date()); // → "Aug 21, 2024, 7:15 PM"

// Detect the user's zone (display only — don't trust as source-of-truth)
Intl.DateTimeFormat().resolvedOptions().timeZone; // → "America/Los_Angeles"

Python

from datetime import datetime
from zoneinfo import ZoneInfo  # stdlib, Python 3.9+

now_utc = datetime.now(tz=ZoneInfo("UTC"))
now_ist = now_utc.astimezone(ZoneInfo("Asia/Kolkata"))
print(now_ist.isoformat())   # → 2024-08-21T19:15:00+05:30

Go

package main

import (
    "fmt"
    "time"
)

func main() {
    loc, _ := time.LoadLocation("Asia/Kolkata")
    fmt.Println(time.Now().In(loc).Format(time.RFC3339))
}

SQL (PostgreSQL)

-- Always store as TIMESTAMPTZ; convert at SELECT.
SELECT created_at AT TIME ZONE 'Asia/Kolkata' AS created_local
FROM events
WHERE created_at > now() - interval '1 day';