Unix Timestamps and Epoch Time, Explained
What a Unix timestamp is, why epoch time ignores leap seconds, how to tell seconds from milliseconds, converting in JS, Python and SQL, and the 2038 problem.
By Udit Agarwal · Updated October 18, 2026
A Unix timestamp is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment known as the Unix epoch. The value 1792238400, for example, is 12:00 UTC on 17 October 2026. Because it is a single number with no time zone attached, epoch time is how most computers store, compare and sort moments in time. Here is how the count works, why it skips leap seconds, how to tell seconds from milliseconds, and what happens in 2038.
Unix time counts seconds from the epoch, 1970-01-01T00:00:00Z. Every day adds exactly 86,400 to the count, the number never jumps for daylight saving, and moments before 1970 are negative: −86400 is midnight UTC on 31 December 1969. Dividing the difference between two timestamps by 86,400 gives the days between them; for spans in months and years, which vary in length, the Date Duration Calculator does the counting.
A few milestones show the scale:
| Timestamp (seconds) | Moment (UTC) |
|---|---|
| 0 | 1970-01-01 00:00:00 |
| 1,000,000,000 | 2001-09-09 01:46:40 |
| 1,700,000,000 | 2023-11-14 22:13:20 |
| 1,792,238,400 | 2026-10-17 12:00:00 |
| 2,000,000,000 | 2033-05-18 03:33:20 |
| 2,147,483,647 | 2038-01-19 03:14:07 |
"Epoch time", "Unix time" and "POSIX time" mean the same thing. The name comes from the Unix operating system, and the POSIX standard gives the exact formula. You meet it in file modification times, log lines, database columns and API responses. The exp and iat claims in a JSON Web Token, for instance, are Unix seconds, which is why the JWT Decoder can show them as dates.
The Earth's rotation is slightly irregular, so since 1972 timekeepers have added 27 leap seconds to UTC to keep it within 0.9 seconds of time measured by the Earth's rotation. The most recent one was 23:59:60 UTC on 31 December 2016.
Unix time ignores them. POSIX treats every day as exactly 86,400 seconds, so a leap second has no number of its own. Systems typically step the clock back by one second, so the timestamp 1483228799 (23:59:59) occurs twice. Some large operators, Google among them, avoid the jump by "smearing" the extra second across many hours.
This has two practical effects. Converting a timestamp to a date is plain arithmetic with no lookup table, because every day has the same length. And subtracting two timestamps gives the elapsed time minus any leap seconds in between, so an interval spanning the end of 2016 comes out one second short. For almost every application that second does not matter. In 2022 the General Conference on Weights and Measures voted to phase out leap seconds by 2035.
Not every system counts in seconds. JavaScript and Java count milliseconds, and some databases and tracing tools go finer still. The quickest way to tell them apart is the number of digits:
| Unit | Digits | 17 Oct 2026, 12:00 UTC | Typical sources |
|---|---|---|---|
| Seconds | 10 | 1792238400 | Unix tools, PHP time(), Python int(time.time()), JWT claims |
| Milliseconds | 13 | 1792238400000 | JavaScript Date.now(), Java System.currentTimeMillis() |
| Microseconds | 16 | 1792238400000000 | some databases, logging and tracing systems |
| Nanoseconds | 19 | 1792238400000000000 | Go UnixNano(), Python time.time_ns() |
The 10-digit rule holds for every date from September 2001 to November 2286, so it covers nearly every timestamp you will meet. Mixing up the units produces errors that are easy to recognize. A millisecond value read as seconds lands tens of thousands of years in the future: 1792238400000 read as seconds is the year 58763. A seconds value read as milliseconds lands in January 1970: 1792238400 read as milliseconds is 21 January 1970. If a converted date says 1970, you have almost certainly passed seconds to something that expected milliseconds.
The millisecond clock also turns up inside identifiers. A version 7 UUID begins with a 48-bit Unix timestamp in milliseconds, as the UUID guide shows.
A Unix timestamp identifies an instant, and that instant has the same timestamp everywhere on Earth. Time zones come in only when you display it. The timestamp 1792238400 is 12:00 in UTC, 13:00 in London, 08:00 in New York, 17:30 in Bengaluru and 21:00 in Tokyo, and all five are the same moment.
Two common bugs come from forgetting this. One is trying to "convert a timestamp to UTC", which has nothing to convert; what people mean is formatting it in UTC. The other is building a timestamp from a local date and time without saying which zone it belongs to. The text 2025-01-31T12:00 is a different instant in every time zone. JavaScript reads a date and time without an offset in the device's local zone, while it reads a date-only string such as 2025-01-31 as midnight UTC. Add Z or an offset like +05:30 and the ambiguity disappears. The time zone guide covers offsets and daylight saving, and the World Clock & Time Zone Converter shows one moment across several cities.
Every mainstream language and database has a one-liner in each direction. Watch which unit each one uses:
| Where | Current Unix time | Timestamp to date |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) |
new Date(1792238400 * 1000).toISOString() |
| Python | int(time.time()) |
datetime.fromtimestamp(1792238400, tz=timezone.utc) |
| PostgreSQL | SELECT extract(epoch FROM now()); |
SELECT to_timestamp(1792238400); |
| MySQL | SELECT UNIX_TIMESTAMP(); |
SELECT FROM_UNIXTIME(1792238400); |
| SQLite | SELECT unixepoch(); |
SELECT datetime(1792238400, 'unixepoch'); |
| Shell | date +%s |
date -u -d @1792238400 (GNU) or date -u -r 1792238400 (macOS) |
A few details catch people out:
Date works in milliseconds, so multiply seconds by 1,000 on the way in and divide on the way out.datetime.fromtimestamp() without a tz argument returns local time, and datetime.utcfromtimestamp() has been deprecated since Python 3.12.to_timestamp() and MySQL's FROM_UNIXTIME() display the result in the session's time zone, so the same query can print different clock times on different servers.unixepoch() in version 3.38; older versions can use strftime('%s', 'now').Timestamps are compact and easy to compare, but nobody can read 1792238400 at a glance. ISO 8601 is the international standard for writing dates and times as text, and its common forms look like this:
2026-10-17T12:00:00Z, where the Z means UTC (it is read "Zulu").2026-10-17T17:30:00+05:30, the same instant written with India's offset.2026-10-17, a date with no time.The format runs from the largest unit to the smallest, so strings in the same format and offset sort correctly as plain text. Many web APIs use RFC 3339, a strict profile of ISO 8601. A sensible split is to store and calculate with timestamps or UTC values, and to use ISO 8601 wherever people or other systems need to read the value. To print a date in a custom pattern instead, the strftime Date Formatter previews tokens such as %Y-%m-%d. ISO 8601 also defines durations, such as PT90M for 90 minutes, which the ISO 8601 Duration Converter turns into 5,400 seconds.
Many older systems store Unix time in a signed 32-bit integer, whose largest value is 2,147,483,647. That many seconds after the epoch is 03:14:07 UTC on 19 January 2038. One second later the counter overflows to −2,147,483,648, which those systems read as 20:45:52 UTC on 13 December 1901.
Modern 64-bit operating systems keep time in 64 bits, which lasts about 292 billion years. The risk sits wherever 32 bits survived: older embedded devices, file formats and protocols with 32-bit time fields, and database columns. MySQL's TIMESTAMP type, for example, only accepts values up to 2038-01-19 03:14:07 UTC. Software that stores future dates meets the limit early, since a 30-year contract signed in 2026 ends in 2056. An unsigned 32-bit counter would last until 06:28:15 UTC on 7 February 2106. JavaScript dates are not affected: they count milliseconds in a 64-bit floating-point number and reach the year 275760.
The Unix Timestamp Converter works in both directions. Paste a timestamp and it shows the moment in your local time, in UTC, as an ISO 8601 string and as a relative phrase such as "3 years ago". In Auto mode it treats any value of 1,000,000,000,000 or more (13 digits and up) as milliseconds and anything smaller as seconds, and it tells you which it used; pick Seconds or Millis to override it. Negative values work for dates before 1970. In the other direction, type a date such as 2025-01-31T12:00:00Z and it returns both the seconds and the milliseconds value. A live clock at the top shows the current Unix time in both units, with copy buttons throughout.
Its limits follow from those rules. It accepts whole numbers only, with no decimals, and has no microsecond or nanosecond mode, so cut 16- and 19-digit values down to 13 digits first. A millisecond value from before September 2001 has 12 digits or fewer, so Auto mode reads it as seconds; choose Millis for old dates. Everything runs in your browser and nothing you enter is uploaded.
What is epoch time? Epoch time is another name for Unix time: the number of seconds since 00:00:00 UTC on 1 January 1970. The epoch is that starting moment. Some systems count milliseconds or smaller units from the same starting point.
How do I convert a Unix timestamp to a date? Paste it into a converter, or format it in code. Check the unit first: JavaScript's Date expects milliseconds, so a 10-digit seconds value has to be multiplied by 1,000 before it is formatted in UTC or local time.
Why does my timestamp show a date in 1970? You passed seconds to something that expects milliseconds, such as JavaScript's Date. Read as milliseconds, 1792238400 is only about three weeks after the epoch. Multiply the value by 1,000.
Is a Unix timestamp in UTC? It is counted from a UTC starting point and does not depend on any time zone, so the same instant has the same timestamp everywhere. A time zone matters only when you turn the number into a clock time.
What happens on 19 January 2038? At 03:14:07 UTC a signed 32-bit timestamp reaches its maximum, 2,147,483,647. Systems that still store time that way will overflow and jump back to December 1901. Systems that store 64-bit time are not affected.
How many digits does a Unix timestamp have? A timestamp in seconds has 10 digits for any date between September 2001 and November 2286. In milliseconds it has 13 digits, in microseconds 16 and in nanoseconds 19.
Does Unix time count leap seconds? No. Every day counts as exactly 86,400 seconds, so the 27 leap seconds added since 1972 have no timestamps of their own.
All Date / Time tools · All guides