Unix Timestamp Converter

About this tool

Epoch ↔ ISO 8601 ↔ local time

Convert Unix timestamps (seconds + milliseconds) to ISO 8601, RFC 2822, and local times in 8 major timezones. Live "current epoch" clock + relative time output.

RT-DEV-083 · Developer Tools

🕒 Current epoch: — —

Unix timestamp (sec or ms)

Or date/time

Formats

Unix (seconds)—

Unix (ms)—

ISO 8601—

RFC 2822 / HTTP—

Relative—

Local time across major timezones

UTC—

Singapore (SGT, +08)—

Tokyo (JST, +09)—

Jakarta (WIB, +07)—

London (GMT/BST)—

New York (EST/EDT)—

Los Angeles (PST/PDT)—

Sydney (AEST/AEDT)—

How to use the Unix Timestamp Converter

Convert from Unix timestamp

Paste any Unix timestamp into the "Unix timestamp" field. The converter auto-detects: 10-digit input is treated as seconds (the standard Unix epoch); 13-digit input as milliseconds (JavaScript's Date convention). Outputs ISO 8601, RFC 2822, relative time, and local time in 8 major timezones simultaneously. Works for any timestamp from 1970-01-01 (epoch zero) to year 2286 (32-bit Unix overflow).

Convert from date/time

Use the "Or date/time" field to pick a calendar date + time using your browser's native picker. The converter computes the equivalent Unix timestamp and all the same outputs. Useful when you have a human-readable timestamp from a log or document and need the epoch value for an API call or database query.

Check live current epoch

The top banner shows the live current epoch + ISO 8601 timestamp, ticking once per second. Useful when debugging "is my timestamp current?" or generating fresh timestamps for testing. Click "Use Now" to populate the converter with the current moment for further manipulation.

Read the timezone outputs carefully

The same Unix timestamp represents the SAME moment in time globally — but local representations differ. Singapore 14:00 SGT = Tokyo 15:00 JST = Jakarta 13:00 WIB = London 06:00 GMT (or 07:00 BST in summer) = New York 02:00 EDT (or 01:00 EST). Use this when coordinating across distributed teams or debugging timezone-related bugs.

Unix timestamps — the universal language of time in computing

A Unix timestamp counts the seconds since 00:00:00 UTC on January 1, 1970 — known as "the epoch". This deceptively simple definition has become the lingua franca of timekeeping across nearly every computing system on Earth. Why? Because it's a single number — comparable, sortable, math-able. A timestamp of 1716566400 represents the same exact moment everywhere in the world, regardless of timezone, DST, calendar reform, or locale conventions. Compare that to "May 24, 2024 at 4 PM": is that Eastern Time? Singapore Time? Which year's DST rules? Does it mean 16:00 or 4:00 AM? Unix timestamps sidestep all that ambiguity by encoding only the universal moment.

The Year 2038 problem

Unix timestamps stored in 32-bit signed integers can represent moments up to 03:14:07 UTC on January 19, 2038. After that, the value overflows and wraps to negative — interpreted as a date in 1901. This is the "Year 2038 problem" or "Y2K38", analogous to Y2K but actually mathematically inevitable rather than a coding oversight. Modern systems use 64-bit signed integers, pushing the overflow date to ~292 billion years in the future. But embedded systems, legacy databases, and old file formats may still use 32-bit timestamps. As 2038 approaches, systems that haven't migrated to 64-bit will fail — similar to Y2K but with concentrated impact on industrial control systems, banking back-end, and old gaming hardware. Most modern programming languages (Python 3, JavaScript Date, Go time.Time, Rust chrono) use 64-bit internally; the calculator handles dates up to year 9999.

The Unix epoch (1970-01-01 UTC) is the moment that doesn't move. Every other date in computing is expressed as an offset from that moment.

Why ISO 8601 beats every other date format

The ISO 8601 standard (1988, updated 2019) defines an unambiguous date-time format: YYYY-MM-DDTHH:mm:ss.sssZ where Z means UTC (offset 0). Example: 2024-05-24T14:00:00.000Z. The key benefits: sortable as text (alphabetical sort = chronological sort, unlike "May 24 2024"); unambiguous (no question whether "05/24" is May 24 or April 5); universal (every modern language parses it); timezone-explicit (Z for UTC, or +08:00 for SGT, etc.). RFC 3339 is a strict subset of ISO 8601 commonly used in JSON APIs. Whenever you store dates as strings (logs, CSV exports, JSON), ISO 8601 is the right choice. Never use "May 24, 2024" or "5/24/24" — both are locale-dependent and parsing-hostile.

The ASEAN timezone politics

Time zones across ASEAN have some quirks worth knowing. Singapore (SGT, UTC+8): historically UTC+7:30; moved to UTC+8 in 1982 by political alignment with Hong Kong. Malaysia (MYT, UTC+8): peninsula was UTC+7:30 until 1982; Borneo states were UTC+8 — all now unified at UTC+8. Indonesia: three time zones! WIB (UTC+7) for Java/Sumatra/West Kalimantan, WITA (UTC+8) for Central/East Kalimantan/Sulawesi/Bali, WIT (UTC+9) for Maluku/Papua. Vietnam (UTC+7), Thailand (UTC+7), Cambodia (UTC+7), Laos (UTC+7): all aligned at +7. Philippines (PST, UTC+8): same as Singapore + Malaysia. Myanmar (MMT, UTC+6:30): the half-hour-offset oddity. None observe DST across ASEAN (tropical regions don't benefit from it). For multi-country tech companies (Grab covers SG/MY/ID/PH/TH/VN), engineering teams universally store timestamps in UTC and present local time per user's locale — exactly the pattern this calculator demonstrates. The calendar quirks (Indonesia spans 3 timezones, Myanmar's 6:30 offset) make UTC storage non-negotiable.

10 Things to Know About Unix Timestamps

Unix epoch = January 1, 1970, 00:00:00 UTC. Unix timestamps count seconds since this moment. Universal across nearly every computing system.

The Year 2038 problem: 32-bit Unix timestamps overflow at 03:14:07 UTC on January 19, 2038. Modern systems use 64-bit (good for 292 billion years).

ISO 8601 is the unambiguous date format: YYYY-MM-DDTHH:mm:ssZ. Sortable as text, parseable by every language, timezone-explicit.

JavaScript timestamps are in milliseconds, not seconds — Date.now() returns ms. Most other languages use seconds. 13 vs 10 digit count distinguishes them.

Unix timestamps don't account for leap seconds. The UTC standard includes ~37 leap seconds since 1972; Unix time pretends they don't exist.

Indonesia spans 3 timezones: WIB (+7) Java/Sumatra, WITA (+8) Bali/Sulawesi, WIT (+9) Maluku/Papua. Most ASEAN unified at +7 or +8.

Singapore was UTC+7:30 until 1982 — moved to +8 to align with Hong Kong + China business hours. No ASEAN country observes daylight saving time.

Myanmar uses UTC+6:30 — one of the few half-hour-offset timezones globally (others: India +5:30, Nepal +5:45, Newfoundland -3:30).

Best practice: store timestamps in UTC, display in user's local time. The calculator demonstrates this: one UTC timestamp, 8 local representations.

The Y2K38 mitigation is mostly complete in consumer software but lingering in embedded systems, legacy databases, and industrial control hardware.

Frequently Asked Questions

A single integer representing seconds elapsed since January 1, 1970 at 00:00:00 UTC (the "Unix epoch"). The value increments by 1 every second. Timestamp 1716566400 represents May 24, 2024 14:00:00 UTC — the same moment everywhere in the world. Used across virtually all programming languages and databases as the universal way to represent a specific moment without timezone ambiguity.
Most languages use seconds — Python time.time() returns float seconds; Go time.Unix() takes seconds; PHP time() returns seconds; SQL DATETIME often stored as seconds. JavaScript is the major exception — Date.now() and new Date().getTime() return milliseconds since epoch. The calculator auto-detects: 10-digit input = seconds, 13-digit = milliseconds. When in doubt, multiply or divide by 1000 to convert between the two. For new code in non-JS languages, prefer seconds; for JavaScript-heavy stacks, milliseconds are unavoidable.
32-bit signed integers can represent values up to 2,147,483,647. As a Unix timestamp, that's 03:14:07 UTC on January 19, 2038. After that, the value overflows and wraps to negative — interpreted as a date in 1901. Systems still using 32-bit timestamps in 2038 will misbehave catastrophically: bank transactions wrong-dated, scheduled tasks misfire, certificate validation fails, embedded systems crash. Modern systems (Python 3, Java, Go, Rust, modern Linux kernels) use 64-bit timestamps which don't overflow until year 292277026596 — essentially never. Y2K38 mitigation in legacy systems is ongoing.
"May 24, 2024" is locale-dependent (different word order in Japanese: 2024年5月24日), ambiguous (5/24/24 in US, 24/5/24 in UK, 24-May-24 in some software), and not sortable as text. ISO 8601 (2024-05-24T14:00:00Z) is unambiguous, locale-neutral, sortable alphabetically = chronologically, and parseable by every language without configuration. RFC 3339 is a stricter subset commonly used in JSON APIs. Always use ISO 8601 for storing dates as strings; reserve "May 24, 2024" only for human display.
Unix timestamps don't include leap seconds. UTC has added ~37 leap seconds since 1972 to keep atomic time aligned with Earth's slowing rotation. Unix time pretends these don't exist — each Unix day is exactly 86,400 seconds. The consequence: a timestamp like 2016-12-31T23:59:60Z (a real UTC moment, leap second day) doesn't exist in Unix time — the Unix clock either freezes for one second or skips ahead, depending on implementation. Most application code never notices, but high-frequency trading + GPS + scientific timekeeping must handle this. The International Bureau of Weights and Measures voted in 2022 to deprecate leap seconds by 2035 — by then, Unix and UTC will drift apart slowly but predictably.
ALWAYS UTC. Storage in local time is a bug source: timezone conversions become application-specific guesses, DST changes break historical data, server migration changes results. Best practice: store all timestamps as UTC (Unix epoch or ISO 8601 with Z); convert to user's local time only at display time. This calculator demonstrates the pattern: one Unix timestamp, multiple local representations. Database schemas should use TIMESTAMP WITH TIME ZONE (Postgres) or BIGINT for Unix epoch; never DATETIME WITHOUT TIME ZONE.
Indonesia spans ~5000 km east-west (similar to the contiguous US). Three zones: WIB (Waktu Indonesia Barat, UTC+7) covers Java, Sumatra, West Kalimantan — the most populous regions. WITA (Waktu Indonesia Tengah, UTC+8) covers Bali, Lombok, Sulawesi, Central/East Kalimantan. WIT (Waktu Indonesia Timur, UTC+9) covers Maluku, Papua. There have been periodic discussions of unifying to a single time zone (under Jokowi's first term) but cultural + business resistance from each region has prevented this. For Indonesian tech companies (Tokopedia, GoTo, Bukalapak, Traveloka): UTC storage is non-negotiable for cross-region operations.
In casual usage, GMT and UTC are interchangeable — both mean "zero timezone offset". Technically: GMT (Greenwich Mean Time) is a timezone (still used in UK winter); UTC (Coordinated Universal Time) is a precise atomic-clock-based time standard. GMT can be ±0.9 seconds from UTC due to Earth's variable rotation; UTC stays atomic-precise with leap seconds. For programming, always use UTC. RFC 2822 specifies "GMT" in HTTP date strings out of historical convention; ISO 8601 uses "Z" (Zulu time, military convention for UTC).
No. All conversions run entirely in your browser via JavaScript using the native Date API + Intl.DateTimeFormat. There's no server roundtrip — open DevTools → Network and confirm zero outbound requests. Your timestamps stay on your device. Safe for sensitive log analysis, security incident timestamps, or any debugging work that shouldn't leave your machine.
Accurate to the IANA timezone database (tzdata) — the same source used by every modern OS + language. This includes historical changes (Singapore moved from UTC+7:30 to UTC+8 in 1982 — the calculator handles dates before 1982 correctly), current DST rules (BST start/end in UK, EDT/EST in US, AEST/AEDT in Australia), and future-scheduled changes. The browser-native Intl.DateTimeFormat API is used; it's updated automatically when timezone rules change globally (e.g. when a country reverses its DST policy). For year-2000+ dates, the conversions are exact; pre-1900 dates have slightly looser accuracy due to imprecise historical records.