Unix Timestamp Converter
Convert Unix timestamps (seconds + milliseconds) to ISO 8601, RFC 2822, and local times in 8 major timezones. Live "current epoch" clock + relative time output.
Unix Timestamp Converter
Formats
Local time across major timezones
How to use the Unix Timestamp Converter
Convert from Unix timestamp
Paste any Unix timestamp into the "Unix timestamp" field. Seconds and milliseconds are told apart by the magnitude of the number, not the length of what you typed: a value whose whole part runs to 13 digits or more is read as milliseconds, because as a second-count it would sit past the year 300,000. That distinction matters — a fractional epoch such as 1234567890.123 is fourteen characters long but ten digits large, and reading it by string length would put it in January 1970. Outputs are ISO 8601, RFC 2822, relative time and local time in eight zones at once. The accepted range is −62,135,596,800 (0001-01-01, the earliest instant the browser will format) to 9,999,999,999, which lands on 20 November 2286 — a ten-digit ceiling, not the 32-bit one; that is January 2038 and is a different number.
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
POSIX.1-2024 defines the Epoch as 00:00:00 UTC on 1 January 1970, and "Seconds Since the Epoch" as a value that approximates the number of seconds that have elapsed since the Epoch
. A single integer, so it is comparable, sortable and subtractable, and it carries no timezone to be wrong about: 1716559200 is one instant, and the eight rows below are eight ways of writing that same instant down.
Where "approximates" does its work
The standard is unusually candid about what it is not giving you, and both caveats are worth reading before you trust a timestamp difference as an elapsed duration.
First, the day is fixed by fiat: As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.
UTC does not oblige. Twenty-seven leap seconds have been inserted since 1972 to keep civil time in step with the Earth's rotation — TAI−UTC now stands at 37 seconds, of which 10 was the offset already in place when the modern scheme began in 1972 — and Unix time absorbs none of them. A leap second is a UTC instant, 23:59:60Z, that has no epoch value at all. RFC 3339's grammar allows 00-60 in the seconds field precisely so it can write one down; this converter cannot represent it, because the number it converts from has nowhere to put it.
Second, POSIX declines to bind the count to reality: The relationship between the actual date and time in Coordinated Universal Time, as determined by the International Earth Rotation Service, and the system's current value for seconds since the Epoch is unspecified
, and how a system realigns itself is implementation-defined. That sentence is what makes leap-second smearing — spreading the extra second across a day, as several large cloud clocks do — a conforming choice rather than a violation. Two conforming machines can disagree by up to a second across a leap event and both be right.
The practice is being retired rather than fixed. Resolution 4 of the 27th General Conference on Weights and Measures, November 2022, decides that the maximum value for the difference (UT1−UTC) will be increased in, or before, 2035
; raising that tolerance is what removes the need to insert leap seconds, and the replacement value is to be settled at the 28th CGPM in 2026.
Before 1970 is off the map
POSIX draws an explicit boundary: If the year is <1970 or the value is negative, the relationship is undefined.
This converter accepts negative epochs anyway, down to 0001-01-01, because ECMAScript's Date defines the arithmetic proleptically and consistently. Treat those results as this page's answer rather than the standard's — a C library, a database, or another language is free to reject the value or to compute it differently, and several do.
The Year 2038 problem
A signed 32-bit time_t tops out at 2,147,483,647, which is 03:14:07 UTC on 19 January 2038; the next second wraps to −2,147,483,648, or 13 December 1901. This is arithmetic rather than an oversight, which is what separates it from Y2K. Widening time_t to 64 bits moves the ceiling past 292 billion years, and current mainstream runtimes have done so — but the type is chosen by whatever compiled the code, so a 32-bit binary on a 64-bit kernel keeps the 2038 limit, and so does any on-disk or on-wire format that fixed four bytes for a timestamp.
Note that this page's own ceiling is neither of those numbers. It stops at 9,999,999,999 seconds — 20 November 2286 — which is simply the largest ten-digit epoch, the shape of value this field is built to take. If you need to test 2038 behaviour, 2147483647 and 2147483648 are the two values to paste; they are well inside the accepted range.
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
ISO 8601 (first published 1988; now ISO 8601-1:2019 and 8601-2:2019) fixes the field order largest-to-smallest, which is the property everything else follows from: a lexicographic sort of the text is a chronological sort of the instants, and there is no argument about whether 05/24 is May or April. RFC 3339 describes itself as a profile of ISO 8601
for Internet protocols — narrower, and the one JSON APIs generally mean. The ISO string this page prints, 2024-05-24T14:00:00.000Z, is valid under both.
One distinction RFC 3339 makes that almost nothing preserves: Z and +00:00 assert that UTC is the preferred reference for the timestamp, whereas an offset of "-00:00"
says the local offset is unknown. Same instant, different claim about what you know. The RFC also fixes the seconds field at 00-60 rather than 00-59, so that a leap second can be written — 2016-12-31T23:59:60Z is a real timestamp under RFC 3339 and has no Unix equivalent.
Why a zone name is not an offset
The rows above are produced by Intl.DateTimeFormat with an IANA zone identifier — Asia/Singapore, not "+08:00" — and that difference is the whole point. An IANA zone is a history of offsets, so the same identifier gives a different answer for different instants, and the converter applies the rule that was in force at the timestamp you entered rather than the rule in force today.
The region gives the cleanest demonstrations of that. Singapore's zone record moved through six offsets before settling: +7:20 and +7:30 in the colonial period, +9 during the Japanese occupation, and finally +8 on 1 January 1982 — so a 1975 timestamp rendered as Asia/Singapore must come out at +7:30, and it does. Peninsular Malaysia shares that 1982 change; the Borneo states were already at +8. Indonesia has never had one zone: WIB (+7) over Java, Sumatra and western Kalimantan, WITA (+8) over Bali, Sulawesi and the rest of Kalimantan, WIT (+9) over Maluku and Papua — one country, three columns in any report. Myanmar keeps a half-hour offset at +6:30, in company with India (+5:30), Nepal (+5:45) and Newfoundland (−3:30). No ASEAN member currently observes daylight saving, which is why the +7 and +8 rows here never shift while London and New York do.
All of which is an argument for storing the instant and deriving the label: an offset written into your data is a fact about one moment, and an identifier is a fact about a place. The IANA database is amended several times a year as governments change the rules, and the browser that renders this page picks those amendments up from the operating system — so the same input can legitimately produce a different local label after an OS update.
What POSIX guarantees about epoch time, and what it deliberately does not
POSIX.1-2024 defines the Epoch as 1970-01-01 00:00:00 UTC and a timestamp as a value that approximates the number of seconds that have elapsed since the Epoch
. The word doing the work is approximates — see facts 05 and 06.
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.
The 86,400-second day is a requirement, not an accident. POSIX.1-2024 §4.19: As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.
UTC does not work that way — 27 leap seconds have been inserted since 1972 (TAI−UTC stands at 37 s, of which 10 s was the 1972 starting offset).
POSIX will not promise your clock is right. §4.19 again: The relationship between the actual date and time in Coordinated Universal Time, as determined by the International Earth Rotation Service, and the system's current value for seconds since the Epoch is unspecified.
How a system reconciles the two is implementation-defined — which is why leap-second smearing is legal.
Negative epochs are outside the standard. POSIX.1-2024: If the year is <1970 or the value is negative, the relationship is undefined.
This page accepts them anyway, back to 0001-01-01, because the browser's Date object defines the arithmetic proleptically — but a C library is under no obligation to agree with it.
Myanmar uses UTC+6:30 — one of the few half-hour-offset timezones globally (others: India +5:30, Nepal +5:45, Newfoundland -3:30).
RFC 3339 distinguishes Z from -00:00. An offset of -00:00 means the local offset is unknown; Z and +00:00 assert that UTC is the preferred reference. Most tooling flattens the two, and the information is lost.
Leap seconds are being retired. Resolution 4 of the 27th CGPM (November 2022) decides that the maximum value for the difference (UT1−UTC) will be increased in, or before, 2035
, with the new value to be proposed for agreement at the 28th CGPM in 2026. Raising that tolerance is what stops leap seconds being inserted.
Frequently Asked Questions
-
POSIX.1-2024 calls it "Seconds Since the Epoch" and defines it as
a value that approximates the number of seconds that have elapsed since the Epoch
, the Epoch being 00:00:00 UTC on 1 January 1970. Timestamp 1716559200 is 24 May 2024 14:00:00 UTC — one instant, carrying no timezone to be misread. "Approximates" is the standard's own hedge: POSIX requires every day to be exactly 86,400 seconds, which UTC's leap seconds do not respect, and it leaves the relationship between the count and real UTC unspecified. -
Seconds are the POSIX unit and what most languages hand you: Python's
time.time(), Go'stime.Unix(), PHP'stime(). JavaScript is the outlier —Date.now()is milliseconds since the epoch — and that single difference is the commonest cause of a date landing in January 1970 or in the year 56000. This page tells the two apart by the size of the number, not by how you typed it: thirteen or more digits in the whole part is read as milliseconds, because as seconds it would be past the year 300,000. That is deliberate — deciding by string length breaks on a perfectly ordinary fractional epoch like1234567890.123, which is fourteen characters and ten digits. When you convert by hand, multiply or divide by 1000; when you design an API, write the unit into the field name. -
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. Anything comparing or ordering timestamps across that boundary sees time run backwards, which is the failure mode to look for rather than a crash. Widening
time_tto 64 bits moves the ceiling to the year 292,277,026,596, and current mainstream runtimes have done it — but the width is fixed by whatever compiled the code and by any format that reserved four bytes on disk or on the wire, so a 32-bit build or an old file header keeps the 2038 limit regardless of the kernel underneath. You can test it here: paste 2147483647 and then 2147483648, both well inside this page's range. -
"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 time does not contain them, by requirement rather than oversight: POSIX.1-2024 states that
as represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds
. UTC has had 27 leap seconds inserted since the modern scheme began in 1972 — the frequently quoted 37 is TAI−UTC, which includes the 10-second offset that already existed in 1972. So 2016-12-31T23:59:60Z is a real UTC instant with no epoch value, and a system meeting one has to repeat a second, skip one, or smear the difference across a day. All three are conforming, because POSIX also says the relationship between the count and actual UTCis unspecified
and the realignment method is implementation-defined; two correct machines can therefore disagree by up to a second across the event. The practice is on its way out: Resolution 4 of the 27th General Conference on Weights and Measures (November 2022)decides that the maximum value for the difference (UT1−UTC) will be increased in, or before, 2035
, with the replacement value to be agreed at the 28th CGPM in 2026. Note the body — that was the CGPM, the treaty conference, not the BIPM secretariat. -
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.
-
Because the country spans roughly 5,000 km east to west, which is more than two hours of solar time. The IANA database carries the three as separate zones: WIB (Waktu Indonesia Barat, UTC+7) over Java, Sumatra and western Kalimantan; WITA (Waktu Indonesia Tengah, UTC+8) over Bali, Sulawesi and the rest of Kalimantan; WIT (Waktu Indonesia Timur, UTC+9) over Maluku and Papua. The practical consequence for anything national is that "today" is a three-valued question — a report bucketed by local calendar day will bucket the same instant differently depending on which island the row came from. Store the instant; derive the label.
-
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.
-
They are exactly as accurate as the IANA time zone database on the machine you are reading this on. The page passes an IANA identifier —
Asia/Singapore, not a fixed+08:00— to the browser'sIntl.DateTimeFormat, so each row is resolved against the rule that was in force at the instant you entered, not the rule in force today. That is checkable here: Singapore's zone record runs 6:55:25 (LMT), then +7:00, +7:20, +7:30, +9:00 through the Japanese occupation, back to +7:30, and finally +8:00 from 1981-12-31 16:00 UTC, which is midnight local on 1 January 1982. Enter a 1975 timestamp and the Singapore row reads +7:30; enter a 1943 one and it reads +9.Two limits follow from that design. The database is amended several times a year as governments change the rules, and the copy in use belongs to your operating system and browser — so an unpatched machine can render a recent change wrongly, and the same input can produce a different label after an update. And for dates before standard time was adopted locally, tzdata records Local Mean Time, which is a longitude calculation for one reference point rather than a clock anyone kept.
Method & sources
How it computes
Converts between POSIX 'Seconds Since the Epoch' (1970-01-01T00:00:00Z) and calendar time, rendering ISO 8601 / RFC 3339, RFC 2822, relative time and eight IANA zones. Seconds and milliseconds are told apart by the magnitude of the value — 13 or more digits in the whole part is milliseconds — not by the length of the typed string. Range: 0001-01-01 to 2286-11-20. Zone rendering is delegated to Intl.DateTimeFormat with IANA identifiers, so historical offsets apply.
What this tool implements
- POSIX.1-2024 §4.19 'Seconds Since the Epoch' is the definition used, including its two disclaimers, which the page now states rather than smooths over: 'each and every day shall be accounted for by exactly 86400 seconds' (so leap seconds have no epoch value) and 'the relationship between the actual date and time in Coordinated Universal Time … and the system's current value for seconds since the Epoch is unspecified' (so leap-second smearing is conforming).
- POSIX.1-2024 also states 'if the year is <1970 or the value is negative, the relationship is undefined'. The tool accepts negative epochs to 0001-01-01 because ECMAScript's Date defines the arithmetic proleptically; the page flags that this is the page's answer, not the standard's.
- The ISO output is RFC 3339 — 'a profile of ISO 8601' — and the page carries two of its distinctions that tooling usually loses: Z/+00:00 assert UTC as the preferred reference while -00:00 means the local offset is unknown, and the seconds field is 00-60 so a leap second can be written (2016-12-31T23:59:60Z), which this converter cannot represent.
- Zone conversion uses IANA identifiers through Intl.DateTimeFormat, never fixed offsets, so each row resolves against the rule in force at the entered instant. The page demonstrates this with Singapore's own record rather than asserting it.
- Seconds-vs-milliseconds detection is by MAGNITUDE, and it is shared, tested logic rather than something this page decides for itself. It was decided by string LENGTH until 13 September 2026, which put the ordinary fractional epoch '1234567890.123' — fourteen characters, ten digits — in January 1970.
- The upper bound 9,999,999,999 is the largest ten-digit epoch (2286-11-20) and is explicitly NOT the 32-bit time_t limit, which is 2038-01-19. The page previously conflated the two.
Sources
- IEEE Std 1003.1-2024 (POSIX.1-2024), Base Definitions §4.19 Seconds Since the Epoch and §4.16 Epoch — the definition, the 86,400-second day, the unspecified relationship to real UTC, and the undefined pre-1970 case: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap…
- RFC 3339, Date and Time on the Internet: Timestamps, IETF, July 2002 — the ISO 8601 profile, the Z / +00:00 / -00:00 distinction in §4.3, and the 00-60 seconds field for leap seconds: https://www.rfc-editor.org/rfc/rfc3339
- ISO 8601-1:2019 and ISO 8601-2:2019, Date and time — Representations for information interchange (first published as ISO 8601:1988): https://www.iso.org/standard/70907.html
- Resolution 4 of the 27th General Conference on Weights and Measures (CGPM), November 2022, 'On the use and future development of UTC' — 'decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035': https://www.bipm.org/en/committees/cg/cgpm/27-2022/resolution-4
- IERS Bulletin C leap-second table (Observatoire de Paris), Leap_Second.dat — TAI-UTC = 37 s since 2017-01-01, from a 1972 starting offset of 10 s: https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat
- IANA Time Zone Database, 'asia' file, Zone Asia/Singapore — the full offset history cited on the page: https://github.com/eggert/tz/blob/main/asia and https://www.iana.org/time-zones
- ECMA-262, ECMAScript Language Specification — Date time value range and Intl.DateTimeFormat, which supply the arithmetic and the zone rendering: https://tc39.es/ecma262/
What can make this go out of date
- The IANA time zone database, indirectly. Every local-time row is resolved by the reader's own browser and operating system, so the answer depends on how recently that machine was patched; tzdata is amended several times a year as governments change rules. The page says so.
- Nothing else. There is no network request at runtime; the live epoch clock reads the client clock, so a machine with the wrong time shows the wrong 'now'.
Abridged — the full review record for this tool runs longer than the list above.
Pick up where you left off
Stored only in this browser — never sent to our servers.