Timezone Converter

One Unix instant, thirteen local clocks

A Unix timestamp describes a single moment for the whole planet. What differs is how that moment is displayed. By default this page shows the current instant live, refreshed every second, across 13 zones: UTC, Casablanca, London, Paris, Dubai, Mumbai, Singapore, Tokyo, Sydney, New York, Chicago, Los Angeles, and São Paulo. Paste a Unix timestamp (seconds, milliseconds, or microseconds) or an ISO 8601 date into the input to freeze the grid on that exact moment. Each zone then uses the UTC offset that applied at that time, daylight saving included. Click Live now to return to the live clock. Each card shows the local time, the local date, the current UTC offset, and the IANA zone name, so you can plan a call or read an incident timeline without mental arithmetic.

The live counter at the top shows the current Unix seconds and ISO 8601 UTC time. All formatting uses your browser’s built-in Intl timezone database — no request leaves your tab.

Why Unix time has no timezone

Unix time counts seconds since 1970-01-01 00:00:00 UTC. The value 1715429912 is Saturday, May 11, 2024 at 12:18:32 UTC everywhere. In Tokyo (UTC+9) that same moment reads 21:18:32; in New York, which was on daylight time (UTC−4), it reads 08:18:32. Store and transmit the timestamp; convert to a zone only at the edge, when a human reads it. Paste 1715429912 into the input above to see exactly that. For every representation of a single timestamp (ISO 8601, SQL, RFC 2822, relative time), use the Unix timestamp converter.

IANA zones vs fixed offsets

An IANA timezone such as Europe/Paris or America/New_York is a named set of rules that records every offset change a region has made, including daylight saving time. A fixed offset such as +02:00 is just a number. Offsets describe one moment; zones describe a place across time.

• Save user preferences as IANA names, not offsets — Paris is UTC+1 in winter and UTC+2 in summer.
• Abbreviations like “CST” are ambiguous (US Central, China Standard, Cuba Standard). Prefer IANA names in data and APIs.
• Offsets are fine inside ISO 8601 strings, e.g. 2024-05-11T14:18:32+02:00, because they describe one instant precisely.

Daylight saving time (DST)

DST shifts local clocks, not Unix time. During a “spring forward” change one local hour never happens; during “fall back” one local hour happens twice. If you schedule by local wall-clock time, pick a rule for those gaps and overlaps. If you schedule by Unix seconds, DST cannot break your math. Regions also change DST policies over time, which is why keeping an up-to-date timezone database matters on servers.

Convert Unix time to a zone in code

const d = new Date(1715429912 * 1000);
new Intl.DateTimeFormat('en-GB', {
  timeZone: 'Asia/Tokyo', dateStyle: 'medium', timeStyle: 'medium',
}).format(d); // "11 May 2024, 21:18:32"

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

dt = datetime.fromtimestamp(1715429912, tz=timezone.utc)
print(dt.astimezone(ZoneInfo("Asia/Tokyo")))  # 2024-05-11 21:18:32+09:00

More languages: Python, PHP, Go. In PostgreSQL, AT TIME ZONE does the same job — see the PostgreSQL timestamp guide.

Common timezone mistakes

• Storing local time without a zone. “2024-05-11 12:18” is ambiguous forever. Store Unix seconds or UTC ISO 8601.
• Hard-coding offsets. +01:00 for Paris is wrong half the year.
• Converting twice. Treating an already-local time as UTC and converting again shifts it by the offset a second time.
• Assuming whole-hour offsets. India uses UTC+5:30 and Nepal UTC+5:45. The Mumbai card shows this clearly.

When a live world clock helps

Distributed teams use this grid to pick meeting slots, on-call engineers use it to read timestamps from colleagues in other regions, and community managers pair it with Discord timestamps, which show every reader the event in their own zone automatically.

Frequently asked questions

Related tools