Unix time, POSIX time, epoch timestamp: the short answer
In everyday code, the three terms mean the same number: seconds since 1970-01-01 00:00:00 UTC. The distinction is where each term comes from. "Unix time" is a convention inherited from early Unix and the C library. "POSIX time" is that same count written down as a formal standard (IEEE Std 1003.1), which fixes every day at exactly 86,400 seconds. "Epoch timestamp" is the most generic of the three — an "epoch" is just a fixed reference instant, and while it almost always means the Unix epoch of 1970, other systems (NTP, GPS, Windows) count from different epochs. The table below maps each term to its standard and how it treats leap seconds.
| Term | Counts | Defined by | Leap seconds | Notes |
|---|---|---|---|---|
| Unix time | Seconds since 1970-01-01 00:00:00 UTC | Convention (Unix / C library) | Ignored | The everyday developer name |
| POSIX time | Seconds since the Epoch, by a fixed formula | IEEE Std 1003.1 §4.16 | Ignored — every day is exactly 86,400 s | The formally specified version of Unix time |
| Epoch timestamp | A count from a fixed epoch (usually the Unix epoch) | Generic term — the epoch varies | Depends on the epoch/system | "Epoch" is the reference instant, not always 1970 |
| Epoch milliseconds | Milliseconds since 1970-01-01 UTC | Same epoch, finer unit | Ignored | 13 digits today; JavaScript and Java default |
- IEEE Std 1003.1 — Seconds Since the Epoch (POSIX §4.16)
- Epoch to Date Converter (tool)
- Date to Epoch Converter
- Unix Timestamp Reference
Use Unix time in code
Use Unix time when you are naming fields, logs, or API values that store seconds since 1970 UTC.
Use POSIX time for standards language
Use POSIX time when you need the formal definition, especially around leap seconds, time_t, or compliance documents.
Use epoch timestamp for generic counts
Use epoch timestamp when the unit or epoch may vary. Then say whether the value is seconds, milliseconds, microseconds, FILETIME, NTP, or GPS time.
What is an epoch timestamp?
An epoch timestamp is a numeric count measured from a fixed reference moment called an epoch. In everyday developer usage, epoch timestamp usually means Unix timestamp: the number of seconds since January 1, 1970 at 00:00:00 UTC. A value of 0 means the exact Unix epoch. Positive values are after 1970; negative values are before it. The word that does the work is "epoch" — it names the starting instant, and everything else is just counting from there. For the plain definition and the meaning of timestamp zero, see Epoch Time Explained; this article focuses on how the three competing names relate.
Timestamp Unix time
In search queries, timestamp Unix time is usually a request for the same 1970-based integer used by Linux, Python, PHP, Go, and databases.
Epoch milliseconds
Epoch milliseconds use the Unix epoch but count milliseconds instead of seconds. They are common in JavaScript Date, Java Instant, and browser APIs.
Unix time vs POSIX time: what the standard says
Unix time and POSIX time refer to the same count, but only POSIX time is formally specified. IEEE Std 1003.1 — the POSIX standard — defines "Seconds Since the Epoch" with an explicit formula that converts a UTC calendar date into a single integer. The defining property of that formula is that it treats every day as exactly 86,400 seconds (60 × 60 × 24). That is a deliberate simplification: it ignores leap seconds, trading astronomical accuracy for a value that is trivial to compute, sort, and store. "Unix time" is the colloquial name for the same quantity, predating the standard; "POSIX time" is what you cite when you need the precise definition.
- POSIX formula: a UTC date maps to one integer, with each day fixed at 86,400 seconds
- Consequence: a Unix/POSIX timestamp follows UTC but never counts the inserted leap seconds
- time_t is the C type that holds it — historically signed 32-bit, now usually signed 64-bit
- Same instant → same value on every conforming system, regardless of timezone or locale
- IEEE Std 1003.1 — Base Definitions, Seconds Since the Epoch
- Leap Seconds Explained (why UTC and Unix time drift)
time_t and POSIX timestamps
In C and POSIX-oriented systems, time_t is the storage type and POSIX timestamp is the definition of the seconds count it usually holds.
Timezone neutrality
A Unix or POSIX timestamp has no timezone. Timezones only appear when you format that instant for a human.
Do Unix time and POSIX time ever actually differ?
For almost all software, no — they are the same number and you can use the terms interchangeably. The differences only surface at the boundary between civil time and physics. Because both ignore leap seconds, a Unix/POSIX timestamp is not a true count of elapsed SI seconds since 1970: it does not include the 27 leap seconds inserted into UTC since 1972. (TAI, a continuous atomic timescale, has run 37 seconds ahead of UTC since 2017.) Around a leap second, a POSIX clock either repeats or skips a second so the day stays exactly 86,400 seconds. Large platforms avoid that discontinuity with leap smearing — spreading the extra second across a whole day so no timestamp is ever ambiguous. If you are doing high-precision timing, scheduling across a leap second, or comparing against GPS or TAI, that is where "Unix" and "POSIX" stop being academic and the leap-second model matters.
Other epochs you'll encounter
"Epoch timestamp" only means "Unix timestamp" by convention. An epoch is simply the instant a clock counts from, and several widely used systems count from a different one. When a value does not decode to a sensible 2020s date with the Unix epoch, a different epoch is often the reason.
- Unix / POSIX epoch — 1970-01-01 UTC; seconds (or ms/µs). The default almost everywhere
- NTP epoch — 1900-01-01 UTC; used by the Network Time Protocol (RFC 5905)
- GPS epoch — 1980-01-06; GPS time has no leap seconds, so it has drifted ahead of UTC (18 seconds as of 2026)
- Windows FILETIME — 1601-01-01 UTC, counted in 100-nanosecond intervals
- JavaScript / Java — the Unix epoch but in milliseconds, which is why those values are 13 digits
When to choose each timestamp term
The right term depends on who will read the value. In code, choose the clearest field name and unit. In documentation, use the term your users search for, then define it once in precise language.
- API fields: createdAtSeconds, createdAtMs, expiresAtUnixSeconds
- Database columns: created_at for native datetime, created_at_epoch for integer seconds
- Logs: unix_time or epoch_seconds when the value is numeric and UTC-neutral
- Standards docs: POSIX time or Seconds Since the Epoch
- User help: epoch timestamp or Unix timestamp, followed by the unit
For developer-facing docs
Spell out the unit the first time the field appears. A name like expiresAtSeconds prevents the next integration from sending milliseconds by mistake.
For support and debugging
Start with the value length. Ten digits points to seconds, 13 to milliseconds, and 16 to microseconds.
Why timestamp since 1970 became standard
The Unix epoch was practical for early Unix systems and became a convention as Unix ideas spread into C libraries, Linux, databases, web servers, and programming languages. A single numeric timestamp is easier to sort, compare, transmit, and store than a localized date string. Once the C library and then POSIX standardized the count, 1970 was locked in across the ecosystem — which is why a value generated on one platform decodes identically on any other.
Epoch timestamp examples
A few known values make the definition easier to remember.
- 0 = 1970-01-01 00:00:00 UTC
- 1 = 1970-01-01 00:00:01 UTC
- 86400 = 1970-01-02 00:00:00 UTC
- 1700000000 = 2023-11-14 22:13:20 UTC
- 1767225600 = 2026-01-01 00:00:00 UTC
Related articles
FAQ
- Is epoch time the same as Unix time?
- In common developer usage, yes. Epoch time usually means Unix time: elapsed seconds since 1970-01-01 00:00:00 UTC.
- What is the Unix time definition?
- Unix time is defined as seconds since 1970-01-01 00:00:00 UTC, not counting leap seconds.
- What is POSIX time?
- POSIX time is the formally specified version of Unix time. IEEE Std 1003.1 ("Seconds Since the Epoch") gives an exact formula that counts seconds since 1970-01-01 00:00:00 UTC and treats every day as exactly 86,400 seconds.
- Why does POSIX time ignore leap seconds?
- By design. The POSIX formula fixes a day at exactly 86,400 seconds so the value is simple to compute and store. As a result a Unix/POSIX timestamp tracks UTC but does not represent the leap seconds inserted into it.
- Is a POSIX timestamp timezone-aware?
- No. A POSIX timestamp represents one instant. Timezones are applied only when formatting that instant as a readable date.
- Are epoch timestamps the same on Windows, Linux, and macOS?
- The Unix epoch (1970-01-01 00:00:00 UTC) is identical across modern platforms and languages, so the same instant yields the same Unix timestamp everywhere. Windows uses its own FILETIME epoch (1601) internally, but standard Unix and POSIX timestamps use 1970.
- Is timestamp Unix time the same as epoch timestamp?
- Usually yes. In developer tools and APIs, timestamp Unix time and epoch timestamp normally mean the same 10-digit Unix seconds value. Confirm the unit, because JavaScript and Java often use 13-digit epoch milliseconds.
- What does timestamp to Unix time mean?
- It usually means converting a readable date string or database timestamp into Unix epoch seconds. If the input is already a 10-digit Unix timestamp, no conversion is needed.