Unix time (also called epoch time or POSIX time) is the near-universal internal representation of time across computing — a single integer counting seconds since a fixed reference point, independent of timezone, calendar format, or locale. Understanding it properly clears up a huge amount of confusion around timestamp bugs, date libraries, and cross-system time synchronization.
The Basic Idea
Instead of storing a date as "year, month, day, hour, minute, second, timezone" — a format that's convenient for humans but awkward for computers to compare and calculate with — Unix time stores a single integer: the number of seconds elapsed since a fixed reference moment. Comparing two moments in time becomes trivial integer subtraction rather than complex calendar arithmetic, and there's no ambiguity about timezone since the value itself has none.
Why January 1, 1970?
The Unix operating system was under active development at Bell Labs in the early 1970s. Developers needed a reference point, and January 1, 1970, 00:00:00 UTC was chosen as a round, recent date at the time — not for any deep technical reason. It became embedded in the system's design and, as Unix and Unix-like systems spread, the convention spread with it, eventually becoming the near-universal standard across virtually all computing platforms, languages, and protocols, whether they descend from Unix or not.
How It's Actually Computed
A Unix timestamp is calculated as: (current UTC time) − (January 1, 1970, 00:00:00 UTC), expressed in seconds. For example, July 2, 2026 at midnight UTC corresponds to a specific large integer — you can verify any date's exact timestamp using our Unix Timestamp Converter. Internally, most systems store this as either a 32-bit or 64-bit signed integer, which matters significantly for long-term validity (see the Year 2038 problem in our dedicated guide below).
The Leap Second Complication
Strictly, Unix time deliberately ignores leap seconds — the occasional extra second added to UTC to account for Earth's slightly irregular rotation. Standard Unix time treats every day as exactly 86,400 seconds, even on the rare days that actually contain a leap second. This means Unix time technically drifts a tiny amount from true elapsed physical time, though the practical impact is negligible for almost all applications. High-precision timing systems (financial trading, scientific instrumentation) that genuinely need leap-second accuracy use alternative time standards like TAI (International Atomic Time) instead.
Common Pitfalls
- Seconds vs milliseconds confusion: JavaScript's
Date.now() returns milliseconds, while most Unix conventions and many other languages use seconds — a 1000x mismatch is one of the most common timestamp bugs in practice.
- Assuming local time instead of UTC: A raw Unix timestamp has no timezone attached — displaying it correctly requires explicitly specifying which timezone to render it in, a step that's easy to accidentally skip.
- 32-bit overflow (Year 2038 problem): Systems still using signed 32-bit integers for timestamp storage will overflow on January 19, 2038 — read our dedicated Year 2038 Problem guide for the full picture.
- Negative timestamps for pre-1970 dates: Valid in most implementations but not universally supported — test explicitly if your application needs to represent historical dates before the epoch.
Use our free Unix Timestamp Converter to convert any timestamp to a human-readable date (or the reverse) instantly, in either seconds or milliseconds, with the exact code snippet for common programming languages included.
FAQs
What is Unix time? +
The number of seconds elapsed since 00:00:00 UTC on January 1, 1970 — a single, timezone-independent integer representing a specific moment, used internally by virtually all computing systems.
Why is Unix time also called epoch time? +
'Epoch' refers to the fixed reference starting point (January 1, 1970), and 'epoch time' is simply an alternate name emphasizing that origin point.
Does Unix time account for timezones? +
No — it's an absolute value with no timezone attached. Converting it to a readable date requires separately specifying which timezone to display it in.
Why do some systems use milliseconds instead of seconds? +
Some platforms, notably JavaScript, chose millisecond precision for finer-grained timing needs — this is purely a platform convention difference, not a different underlying concept.
What happens with leap seconds in Unix time? +
Standard Unix time ignores them, treating every day as exactly 86,400 seconds, which causes a tiny, generally negligible drift from true elapsed physical time over the years.
Can Unix time represent dates before 1970? +
Yes, using negative values, though support isn't universal across all systems and libraries — test explicitly if this matters for your application.
Is Unix time the same across every country and timezone? +
Yes — that's precisely its purpose. The same Unix timestamp value refers to the same absolute moment everywhere; only its human-readable display varies by timezone.
What is POSIX time? +
Another name for the same concept — POSIX (the standard Unix-like systems conform to) formally defines this time representation, so 'POSIX time' and 'Unix time' are used interchangeably.
How precise is a standard Unix timestamp? +
The base standard is second-level precision, though millisecond, microsecond, and even nanosecond variants exist in different systems and APIs for higher-precision timing needs.
Why did Unix choose 1970 instead of some other year? +
It was chosen somewhat arbitrarily by early Unix developers at Bell Labs as a round, recent date at the time of the system's design in the early 1970s.
Does Unix time drift over long periods due to leap seconds? +
There's a small cumulative drift from ignoring leap seconds, but it remains negligible (a matter of tens of seconds total) for the vast majority of practical applications outside high-precision scientific or financial timing systems.
How do I get the current Unix timestamp? +
Most languages have a built-in function — Math.floor(Date.now()/1000) in JavaScript, time.time() in Python, or you can simply check the live counter on our Unix Timestamp Converter.
Is Unix time used outside of Unix-based operating systems? +
Yes — despite its name, it's the de facto standard across virtually all modern computing platforms, including Windows internals in many contexts, nearly all programming languages, and most network protocols and APIs.
What's the difference between Unix time and ISO 8601? +
Unix time is a single integer with no built-in human readability. ISO 8601 is a structured, human-readable string format (like 2026-07-02T00:00:00Z) that explicitly includes date, time, and timezone components.
Can two different moments have the same Unix timestamp? +
No — by definition, each integer value corresponds to exactly one unique second since the epoch, making it an unambiguous way to represent a specific moment in time.