What Is a Unix Timestamp?

A Unix timestamp is the number of seconds that have passed since 00:00:00 UTC on January 1, 1970 — the 'Unix epoch.' Computers use it because a single integer is simpler to store, compare, and sort than a calendar date. For example, October 4, 2026 at 00:00 UTC is timestamp 1791072000. Convert timestamps free with our Unix timestamp converter.

The short answer

A Unix timestamp — also called epoch time or POSIX time — represents a moment as one integer: the count of seconds since midnight UTC on January 1, 1970. That date is the 'epoch,' an arbitrary zero point the early Unix designers picked. The number only ever goes up, one second at a time, which makes timestamps trivially easy for computers to compare, subtract, and sort — no month tables, no leap-year logic, no time-zone math. When an API returns "created_at": 1791072000, it is telling you the event happened 1,791,072,000 seconds after the epoch, which works out to October 4, 2026. Negative timestamps count backward: -86400 is exactly one day before the epoch, December 31, 1969.

Why January 1, 1970?

The epoch dates to the early 1970s at Bell Labs, where Ken Thompson and Dennis Ritchie were building Unix. They needed a simple zero point for timekeeping, and the start of the decade they were working in was the obvious choice — early Unix actually used January 1, 1971 first, then shifted to 1970 for roundness. It stuck because Unix spread everywhere: C adopted it, then the internet's protocols, then nearly every operating system and database. Today epoch time is the closest thing computing has to a universal clock. One quirk worth knowing: Unix time officially ignores leap seconds — the extra seconds occasionally added to keep UTC aligned with Earth's rotation. So strictly speaking, every day is exactly 86,400 Unix seconds, even on days that physically contain a leap second.

Seconds, milliseconds, and microseconds

Not all timestamps count seconds. A 10-digit timestamp like 1791072000 counts seconds — the classic Unix form. A 13-digit timestamp like 1791072000000 counts milliseconds, and a 16-digit one counts microseconds. JavaScript's Date.now() returns milliseconds, which is why web developers constantly meet 13-digit values; Python's time.time() returns fractional seconds. Databases vary: some store seconds, some milliseconds, some microseconds. The digit-length trick is the fastest way to tell them apart: 10 digits means seconds, 13 means milliseconds, 16 means microseconds. Mixing them up is a classic bug — interpreting a millisecond timestamp as seconds lands you in the year 58,000. When in doubt, count the digits, and use a converter that auto-detects the unit.

How to read a timestamp at a glance

You can estimate any timestamp with one division. A year averages 31,556,952 seconds (365.2425 days), so dividing a timestamp by that number gives years since 1970. Take 1791072000: dividing yields about 56.75, so 1970 + 56.75 lands in the second half of 2026 — and indeed it is October 4, 2026. For a finer estimate, remember a few landmarks: 1,000,000,000 was September 2001, 1,500,000,000 was July 2017, 1,700,000,000 was November 2023. Each additional ~31.5 million seconds is another year. This will not give you the day, but it tells you instantly whether a timestamp means last week, last decade, or the distant future — which is usually all you need when scanning logs or debugging an API response.

Timestamps are always UTC — and that is the point

This is the single most useful thing to understand about epoch time: a Unix timestamp has no time zone. 1791072000 is simultaneously midnight in London, 8 p.m. in New York, and 5 p.m. in Los Angeles on October 3-4 — it names one instant, and every time zone just renders that instant differently. This is exactly why computers love timestamps: all the messy time-zone conversion happens at display time, once, instead of being baked into stored data. Bugs happen when developers forget this and treat a timestamp as local time, or store 'midnight local' as if it were universal. The rule: store and transmit UTC timestamps, convert to local time only when showing them to a human. Every correct date system you have ever used follows this rule.

The Year 2038 problem

On January 19, 2038 at 03:14:07 UTC, the timestamp hits 2,147,483,647 — the largest value a signed 32-bit integer can hold. One second later it overflows to -2,147,483,648, which reads as December 13, 1901. Any system still storing time in 32 bits will think it has traveled 137 years into the past. This is the Y2K problem's less-famous sibling, and it is real for embedded systems, old file formats, and legacy databases. The fix is 64-bit time, which pushes overflow roughly 292 billion years out — comfortably past the heat death of the universe. Most modern systems migrated years ago, but the long tail of 32-bit firmware in cars, routers, and industrial equipment is why engineers still audit for it. If you maintain anything that stores timestamps, check the integer width now, not in 2037.

Where you will meet Unix timestamps

Timestamps are the plumbing of the internet, so you meet them constantly once you know where to look. REST APIs return created_at and updated_at as epoch seconds. JWT tokens carry iat (issued at) and exp (expires) claims as timestamps — that is how your login session knows when to die. Databases store row creation times as integers for fast range queries. File systems record modification times in epoch seconds — that is what ls -l converts for display. Logs stamp every line with epoch time so events from servers in different time zones sort correctly. Cookies carry expires as a timestamp. Even countdown math is timestamp subtraction under the hood. Whenever software needs 'when,' it reaches for a number, not a calendar.

Negative timestamps: dates before 1970

The epoch is a zero point, not the beginning of time — timestamps simply go negative before it. December 31, 1969 at 00:00 UTC is -86400, one day of seconds backward. The Apollo 11 moon landing (July 20, 1969) is roughly -14,188,800. Negative timestamps work fine in 64-bit systems and in most modern languages, but they expose old bugs: some libraries, date pickers, and especially 32-bit or unsigned-integer code mishandle them, wrapping to absurd future dates. If your application handles birth dates, historical records, or anything before 1970, test the negative range explicitly. It is one of those edge cases that works perfectly in development and breaks spectacularly in production — usually discovered by the first user born before the epoch.

Converting by hand vs by tool

The hand method is the division trick from the reading section: divide by 31,556,952 for years, take the remainder for finer detail — or walk the calendar forward from a known landmark. It is satisfying but slow, and nobody does it twice. In code, every language has a one-liner: Python's datetime.fromtimestamp(1791072000, tz=timezone.utc), JavaScript's new Date(1791072000 * 1000), and the shell's date -d @1791072000. But for a one-off conversion — reading a log line, checking a token's expiry, decoding an API response — opening a REPL is overkill. That is what converters are for: paste the number, get the human date, see the weekday, the ISO string, and the relative time ('3 days ago') in one glance, with seconds-versus-milliseconds auto-detected so the digit-length trap cannot bite you.

Convert any timestamp in one click

Paste any timestamp into our free Unix timestamp converter — 10, 13, or 16 digits, auto-detected — and get the exact UTC date and time, your local equivalent, and the ISO 8601 string instantly. It runs entirely in your browser, so nothing you paste ever leaves your device. Counting down to a date instead? Our guide to how many days until any date covers the calendar math. Wondering how old something is to the day? See what your exact age is — the same borrowing arithmetic, explained.