POSIX Time, Unix Time and Epoch Time
POSIX time, Unix time, epoch time and Unix timestamp all name the same value: seconds elapsed since 1 January 1970 UTC, with every day counted as exactly 86,400 seconds. The different names come from different documents describing it, not from different numbers.
What the POSIX standard actually says
POSIX (IEEE Std 1003.1) defines "seconds since the Epoch" with an explicit formula that converts a broken-down UTC date into a single number. The formula multiplies days by 86,400 and adds hours, minutes and seconds. Crucially, it has no term for leap seconds — which is why POSIX time is not a true count of elapsed physical seconds, and why it repeats a value whenever a leap second is inserted.
The standard also fixes the epoch itself at 1 January 1970 00:00:00 UTC, and specifies the type as time_t. It deliberately does not fix the width of time_t, which is the reason the 2038 rollover is an implementation problem rather than a standards problem.
Where the terms differ in practice
- POSIX time — the formal name, used when the exact standard definition matters, such as in specifications or when discussing leap-second behaviour.
- Unix time — the everyday engineering term for the same number.
- Epoch time — the same again, emphasising that it is measured from a fixed origin.
- Unix timestamp — usually refers to a specific value rather than the concept.
- UTC — a time standard, not a number. A timestamp is expressed in UTC, but UTC itself is not a timestamp.
Related but genuinely different scales
- TAI — International Atomic Time, which does count every physical second and is currently 37 seconds ahead of UTC. Unlike POSIX time, TAI never repeats a value.
- GPS time — counts from 6 January 1980 and ignores leap seconds, so it drifts from UTC by a fixed and growing offset (18 seconds as of 2026).
- Windows FILETIME — 100-nanosecond intervals since 1 January 1601 UTC. Converting to Unix time means dividing by 10,000,000 and subtracting 11,644,473,600.
- Mac absolute time — seconds since 1 January 2001 UTC. Add 978,307,200 to get Unix time.
- Excel serial dates — days since 0 January 1900, with a deliberate bug treating 1900 as a leap year.
Why the leap-second detail matters
If you are measuring durations across a leap second — in scientific instrumentation, finance, or distributed consensus — POSIX time will under-count by one second, and can hand you the same timestamp twice. For almost everything else, the simplicity is worth far more than the accuracy, which is why the entire industry runs on it.
Frequently asked questions
Is POSIX time the same as Unix time?
Yes. POSIX time, Unix time, epoch time and Unix timestamp all refer to the number of seconds since 1 January 1970 UTC, with every day counted as exactly 86,400 seconds. The names come from different documents, not different values.
Does POSIX time count leap seconds?
No. The POSIX formula for seconds since the Epoch has no leap-second term, so a leap second causes the same value to repeat rather than the count to advance.
What is the difference between UTC and a Unix timestamp?
UTC is a time standard; a Unix timestamp is a number. Timestamps are expressed in UTC, but UTC itself is not a number and carries no epoch.
How does TAI differ from POSIX time?
TAI counts every physical second and is currently 37 seconds ahead of UTC, never repeating a value. POSIX time skips leap seconds, so it stays aligned to civil time but is not a true elapsed-second count.