Unix Timestamps Explained (And When You Actually Need Them)

Buried in almost every log file, database row, and API response is a number like 1793664000. It does not look like a date, but it is one: that is Tuesday, November 3, 2026, at midnight UTC, written as a Unix timestamp. If you debug APIs, read server logs, or build anything that schedules or expires, you will run into these numbers constantly. This guide explains what they are, where they came from, the famous bug hiding in them, and when you should use them instead of a normal date string.

What Is Unix Time?

A Unix timestamp (also called Unix time, epoch time, or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970, excluding leap seconds. That starting moment is called “the epoch.”

Because it is a single number counting up from a fixed zero point, Unix time has properties that date strings cannot offer:

• It is timezone-neutral. 1793664000 means the same instant everywhere on Earth. There is no “is this Tokyo time or New York time?” ambiguity; rendering it in a local timezone is a separate, final step.
• It sorts naturally. Earlier events have smaller numbers. Ordering by a timestamp column is trivial, unlike comparing strings like 11/03/2026 and 03/11/2026, which flip depending on convention.
• Arithmetic is easy. “Expires in 24 hours” is now + 86400. “How long ago?” is subtraction. No calendar math required.
• It is compact. Ten digits versus 19+ characters for 2026-11-03T00:00:00Z.

One quirk worth knowing: Unix time ignores leap seconds, the occasional one-second adjustments added to astronomical time. When a leap second occurs, a Unix timestamp repeats or skips a second. For everyday computing this is by design, not a bug; the POSIX standard defines it this way to keep the day count exact at 86,400 seconds.

Why January 1, 1970?

Nothing cosmically significant happened that morning. The early Unix developers simply needed a convenient zero point for the system clock, and the start of the 1970s was recent enough to keep numbers small with the integer widths of the day and old enough to predate anything the system would need to represent. Earlier versions of Unix actually counted time in smaller units from 1971 before the format settled on seconds from the start of 1970. It stuck, and half a century later the entire computing stack, from Linux servers to your phone, still counts seconds from that arbitrary New Year.

The Y2038 Problem

Here is where history catches up. Many older systems stored Unix time as a signed 32-bit integer, which maxes out at 2,147,483,647. That many seconds after the epoch lands on 03:14:07 UTC on January 19, 2038. One second later, a signed 32-bit counter wraps around to a large negative number, which most software will interpret as December 13, 1901.

In practice, the fix is already largely done: modern 64-bit systems use a 64-bit time type, which will not overflow for roughly 290 billion years. But 32-bit embedded systems, older database schemas, and legacy file formats that store 32-bit timestamps remain a real concern in industrial equipment, vehicles, and old software that quietly keeps running. Y2038 is the same species of bug as Y2K: not dramatic on modern hardware, but genuinely dangerous wherever old code meets long-lived systems.

The practical takeaway for developers: never invent your own timestamp formats, and treat 32-bit timestamp fields in old schemas as a debt to pay off, not a permanent fixture.

What about dates before 1970?

Timestamps before the epoch are simply negative numbers: -3600 is 23:00 UTC on December 31, 1969. This matters more often than you would expect, because birthdates, incorporation dates, and historical records all predate 1970, and any system storing them as epoch values has to handle negatives. Signed 32-bit storage bites here too: the smallest representable timestamp bottoms out at December 13, 1901, so truly old dates cannot fit at all. Most databases offer native date types without that floor, which is a useful reminder that epoch seconds are an excellent interchange and computation format, but not automatically the right storage type for every kind of date.

Epoch Seconds vs ISO 8601

The main alternative to Unix time is ISO 8601, the human-readable standard: 2026-11-03T00:00:00Z. Both represent the same instant. They just serve different jobs.

	Unix timestamp	ISO 8601
Example	1793664000	2026-11-03T00:00:00Z
Human-readable	No	Yes
Timezone handling	Inherently UTC	Timezone suffix required
Sorting and comparison	Trivial numeric compare	String compare works only with consistent formatting
Arithmetic (add a day)	+ 86400	Requires date parsing
Best for	Storage, logs, APIs, expiry math	Display, configuration, interchange with humans

A sane default: store and compute in epoch seconds (or ISO 8601 in UTC), render in the user’s timezone only at display time. Mixing the two carelessly is how “expires_at” columns end up off by exactly 3600 seconds for half the year.

When Developers Actually Need Timestamps

Concrete cases where epoch time is the right tool:

• Log correlation. Every log line gets a timestamp; grep a window of epoch seconds across services and the same instant lines up exactly, with no timezone translation.
• Token and session expiry. JWTs commonly carry exp as epoch seconds. Checking exp < now is one integer comparison.
• Caching. Cache-Control and ETag logic boils down to comparing last-modified timestamps.
• Scheduling and retry backoff. “Retry at now + 300” and “run every 3600 seconds” are simple in epoch time.
• Database keys and event ordering. A bigint timestamp column indexes and sorts cheaply.

And the classic gotcha: JavaScript uses milliseconds. Date.now() returns epoch milliseconds (thirteen digits today), while most APIs and JWTs use seconds (ten digits). Paste a millisecond value where seconds are expected and your “2026” event lands in the year 56,000-something. If a timestamp is thirteen digits, it is milliseconds; ten digits, seconds.

Converting Timestamps with the Timestamp Converter Tool

Reading epoch numbers in your head is not a skill worth developing. Our free Timestamp Converter does the translation in your browser, with no signup.

Timestamp to date:

1. Open the Timestamp Converter.
2. Paste a Unix timestamp into the input field. Results appear as you type.
3. Read the output: the converter shows the UTC time and the ISO 8601 representation side by side, so you can copy whichever format your task needs.

Date to timestamp:

1. Switch to date input mode and pick or type the date and time.
2. Read the epoch value in both seconds and milliseconds, each with a copy button, which removes the seconds-versus-milliseconds guesswork entirely.

The tool also displays your browser’s timezone, so you can sanity-check how the instant renders locally. Everything computes client-side; nothing is sent anywhere.

Related Conversions

Two adjacent tools round this out. When you are doing duration math by hand, the Unit Converter includes a time category for converting between seconds, minutes, hours, and days (86,400 seconds in a day, 600 in ten minutes, and other numbers you should not memorize). And when a timestamp needs to become a local time for a meeting or a deadline across regions, the Timezone Converter handles the local rendering step that epoch time deliberately leaves to the end.

Try the Tool

The next time a ten-digit number shows up in a log line or an API payload, paste it into the Timestamp Converter and get the UTC time and ISO 8601 date instantly. It is free, requires no signup, and runs entirely in your browser.