Working with Unix Timestamps: Epoch Time Made Simple

Open an API response or a database row and you'll often find a date stored as a plain number like 1751760000. That's a Unix timestamp, and it's how a huge amount of software tracks time. This guide explains what that number means, why computers count time this way, and the gotchas — seconds vs. milliseconds, time zones, and the Year 2038 problem.

What a Unix timestamp is

A Unix timestamp is the number of seconds that have elapsed since a fixed moment called the epoch: 00:00:00 UTC on 1 January 1970. So 0 is the epoch itself, 60 is one minute past it, and 1751760000 is a moment in 2025. It's just a running count of seconds.

Why count seconds from 1970?

Representing time as a single integer is enormously convenient for computers. Comparing two moments becomes comparing two numbers; finding the gap between them is subtraction; sorting events is just sorting integers — all with no calendars, months, leap years, or time zones to reason about. The 1970 starting point is a historical choice from the early days of the Unix operating system that simply stuck.

The seconds-vs-milliseconds trap

This is the mistake almost everyone hits at least once. Unix timestamps are classically in seconds, but many systems — JavaScript in particular — use milliseconds (thousandths of a second). The two differ by a factor of 1000:

seconds:       1751760000
milliseconds:  1751760000000

Feed a seconds value into something expecting milliseconds and your date lands in 1970; do the reverse and it lands tens of thousands of years in the future. The quick sanity check: a current timestamp in seconds is 10 digits; in milliseconds it's 13. When a converted date looks absurd, this is almost always why.

Time zones and UTC

A key strength of Unix timestamps: the number itself is always in UTC. It represents one exact instant, the same for everyone on Earth. The timestamp 1751760000 is a single moment; whether that's shown as 4 PM in London or 11 AM in New York is purely a display choice applied at the end. Storing time as a UTC timestamp and converting to local time only when you show it avoids a whole category of time-zone bugs. To see the same instant across different regions, a time-zone converter is the tool for the job.

Converting to and from human dates

You'll constantly need to go both directions — turning a timestamp into a readable date to debug a log, or turning a date into a timestamp to query an API. Our Unix timestamp converter does both instantly and shows the result in your local time and UTC. To measure the gap between two dates instead, the date difference calculator handles that directly.

The Year 2038 problem

Older systems store the timestamp as a signed 32-bit integer, which can only count up to 2,147,483,647. That ceiling is reached at 03:14:07 UTC on 19 January 2038— one second later the counter overflows and wraps around to a negative number, throwing dates back to 1901. It's the same class of bug as Y2K. The fix is already widespread: use a 64-bit integer, which pushes the limit some 292 billion years out. Most modern software is fine, but it's worth knowing when touching legacy systems.

Quick reference

• A Unix timestamp = seconds since 1 Jan 1970 UTC.
• 10 digits = seconds; 13 digits = milliseconds.
• The value is always UTC — apply time zones only when displaying.
• 32-bit storage breaks in 2038; 64-bit does not.