Unix Timestamps Explained: Convert Epoch Time to Human Dates

The number in your logs

You are debugging an API response and a field reads 1768521600. Your database stores created_at the same way. That integer is a Unix timestamp — one of the most common ways software records a moment in time — and being able to translate it into a real date, in the right time zone, is a daily task for most developers.

What epoch time actually is

A Unix timestamp is the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, a moment called the Unix epoch. It has two properties that make it popular: it is always in UTC (no time zone ambiguity in storage), and it is a single sortable integer. To display it to a human you convert it to a local date; to compare two events you just subtract.

The critical gotcha is the unit. Classic Unix time is measured in seconds, but many languages and JSON APIs use milliseconds. A quick rule of thumb: a 10-digit number is seconds, a 13-digit number is milliseconds. Mixing them up shifts your dates by a factor of 1000 — turning a 2026 date into the year 55000 or 1970.

Converting in code

In JavaScript, Date works in milliseconds, so you multiply or divide by 1000 when crossing to and from Unix seconds:

// Current Unix time in SECONDS
Math.floor(Date.now() / 1000);        // 1768521600

// Timestamp (seconds) -> human date, UTC
new Date(1768521600 * 1000).toISOString();
// "2026-01-16T00:00:00.000Z"

// A human date -> Unix seconds
Math.floor(new Date("2026-01-16T00:00:00Z").getTime() / 1000);
// 1768521600

Python keeps everything in seconds and lets you pin the time zone explicitly:

from datetime import datetime, timezone

# Timestamp -> aware datetime in UTC
datetime.fromtimestamp(1768521600, timezone.utc)
# datetime.datetime(2026, 1, 16, 0, 0, tzinfo=timezone.utc)

# datetime -> Unix seconds
int(datetime(2026, 1, 16, tzinfo=timezone.utc).timestamp())  # 1768521600

When you just need a quick answer without opening a REPL, paste the number into the Unix Timestamp Converter. It shows the date in UTC and your local zone at once, and converts a picked date back to a timestamp — all in the browser, with nothing sent to a server.

Common pitfalls

• Seconds vs milliseconds. Confirm the unit before you convert. If a date lands in 1970 you divided a milliseconds value; if it lands far in the future you forgot to multiply seconds.
• Assuming local time. The stored epoch is UTC. Any "off by a few hours" bug is almost always a time-zone display issue, not bad data.
• The year 2038 problem. Systems that store the timestamp in a signed 32-bit integer overflow at 2038-01-19 03:14:07 UTC. Use 64-bit integers for anything long-lived.
• Leap seconds. Unix time deliberately ignores them, so it is not a perfect count of physical seconds — fine for almost everything, but worth knowing for high-precision work.

Where timestamps show up next

Once you are comfortable reading epoch values, the same skill helps elsewhere. Scheduled jobs, for example, fire at wall-clock times rather than epoch seconds; if you are decoding one of those, the Cron Expression Parser explains the schedule in plain English. And if a timestamp arrives as an unusual integer, a Number Base Converter can rule out a hex-versus-decimal mix-up.

Conclusion

Unix timestamps are simple once you internalize two facts: they count seconds from 1970 in UTC, and the unit (seconds or milliseconds) is where bugs hide. Keep storage in UTC, convert only at the display layer, and reach for a converter whenever you need to sanity-check a value at a glance.