What is Unix time? A complete guide

If you have ever copied a number like 1745301600 out of a database log and wondered what date it was supposed to mean, you have met Unix time. It is the number of seconds that have passed since midnight on 1 January 1970, in UTC, and it is everywhere: in operating systems, log files, JWT tokens, REST APIs, IoT firmware, file metadata, and the cookies in your browser.

Despite being so common, Unix time has a few quirks that bite developers who treat it as “just a number”. This guide covers what it is, why it works the way it does, and the gotchas that show up the moment you do something more interesting than print the current second.

A single number, no timezone

A Unix timestamp is a single integer. It does not carry a timezone, a calendar system, or a string format. It is just “seconds since the epoch”, where the epoch is the agreed-upon zero point: 1970-01-01T00:00:00Z.

That Z matters. Unix time is defined in UTC, so the same instant in time produces the same number everywhere on Earth. When your phone in Oslo and a server in Tokyo both record 1745301600, they mean the same physical moment — even though the human-readable clock on each side reads something completely different.

This is the whole point of Unix time, and the reason it is the dominant way to store and exchange timestamps between systems. You don’t have to negotiate a timezone, agree on a date format, or worry about whether someone wrote 12/04/2026 and meant April or December.

Why 1970?

The first edition of Unix shipped in 1971, and the developers needed a starting point for the kernel’s internal clock. They picked the start of 1970 because it was a recent, round date that gave plenty of headroom for past file timestamps without wasting too many bits on history.

There are older epoch points in computing — TAI’s 1958, NTP’s 1900, MS-DOS’s 1980 — but Unix time won by being simple, by being part of the C standard library (time_t plus time()), and by being baked into POSIX. Anything that descends from Unix uses it: Linux, macOS, BSD, Android, iOS, every server-side language you have ever shipped to production. Even Windows surfaces it in many APIs, even though its native FILETIME counts 100-nanosecond intervals from 1601.

If you want a fun aside: NTP picked 1900 because it was easier to do astronomical math from a round century. Unix picked 1970 because it was just now-ish in 1971.

Seconds — except when they aren’t

The Unix specification says “seconds”. Most code in the wild agrees. But you will run into systems that store the same kind of value at higher resolution and call it the same thing:

Unit	Magnitude of “now”	Where you’ll see it
seconds	10 digits	date +%s, JWT iat/exp, most REST APIs
milliseconds	13 digits	Date.now() in JavaScript, Java’s System.currentTimeMillis
microseconds	16 digits	Postgres timestamp internals, some logging pipelines
nanoseconds	19 digits	Go’s time.Now().UnixNano(), observability tooling

The painful part: nothing about the number itself tells you which unit it is in. A stray factor of 1,000 can put you 31 years off, and unit-confusion bugs are some of the most common timestamp bugs in production. If you are unsure, use the rule of thumb in the seconds vs milliseconds vs microseconds guide, or paste the value into the Unixdates converter and let auto-detect handle it.

Reading and writing Unix time

In practice, most languages have a one-liner for “now”:

// JavaScript
const seconds = Math.floor(Date.now() / 1000);

# Python
import time
seconds = int(time.time())

// Go
seconds := time.Now().Unix()

# Shell
date +%s

The reverse direction — turning an integer back into a calendar date — is where the timezone you display in matters. The number itself is UTC, but what your user sees is up to you. We have a whole guide on timezones and Unix time if you want to dig in.

What Unix time isn’t good at

Unix time is wonderful for moments — “this transaction happened then”. It is much worse at representing two related concepts that beginners often try to cram into it:

Calendar dates. “Jan’s birthday is on the 22nd of April” is not a moment in time. There is no specific UTC second that corresponds to it; the date floats with whatever timezone you are looking at it from. If you store a birthday as Unix time, you will inevitably ship a bug where users in Auckland see the wrong day. Use a DATE column or an ISO date string like 2026-04-22 instead.

Wall-clock durations. Unix time does not count leap seconds. If you subtract two timestamps that straddle a leap second, you will be one second off from the actual elapsed wall-clock time. For most software this doesn’t matter — but if you are timing sub-second physics, billing latency at the millisecond, or coordinating high-frequency trades, you want a monotonic clock instead.

The 2038 problem

If you store Unix time in a signed 32-bit integer, you run out of headroom on 19 January 2038 at 03:14:07 UTC. After that second, the counter overflows and wraps to a negative number that decodes as a date in 1901. This is the Year 2038 problem, and it is real — there is still 32-bit code out there in routers, embedded devices, and old database schemas.

Modern systems use 64-bit integers, which give you about 292 billion years of headroom. The fix is mostly a matter of finding and migrating the stragglers. We have a full breakdown in the linked guide.

When not to use Unix time

Unix time is the right answer for:

• API requests and responses where machines talk to machines
• Database columns where you want to sort or do “events in the last 24 hours” queries
• Inter-service messages where you can’t trust everyone to agree on a timezone
• Logs and metrics

It is the wrong answer for:

• Anything a human will read directly without rendering — use ISO 8601 (2026-04-22T08:00:00Z)
• Calendar dates without a specific time — use a DATE type
• Anything where you need to preserve the original timezone the event was recorded in (e.g. “the meeting was at 9am Oslo time”) — store both the instant and the timezone

Try it

If you have a number on your screen right now and want to know what date it represents, paste it into the Unixdates converter. It auto-detects seconds, milliseconds and microseconds, and shows the result in your local timezone, UTC, ISO 8601 and as a relative time.