Epoch Time Explained: What Is Unix Timestamp Zero?
Unix timestamp 0 is January 1, 1970 at 00:00:00 UTC. Learn why that date became the Unix epoch, what negative timestamps represent, how epoch seconds/milliseconds/microseconds differ, and what limits apply to modern systems.
What Unix timestamp 0 represents
Every Unix timestamp counts elapsed time since a single reference point: January 1, 1970 at 00:00:00 UTC. In the original Unix definition the unit is seconds, so timestamp 0 is exactly midnight UTC on January 1, 1970 and timestamp 86400 is exactly 24 hours later. Modern systems also use milliseconds, microseconds, and nanoseconds, but the reference point is the same. Every positive value represents a moment after the epoch; every negative value represents a moment before it.
Why January 1, 1970?
The date was chosen by Unix developers at Bell Labs in the early 1970s as a practical reference point slightly before Unix itself was created. It needed to be early enough that normal system timestamps would be positive, recent enough to fit into the small integer ranges of early computers, and simple enough to verify mentally. Once Unix became influential, programming languages, operating systems, databases, log formats, and network protocols inherited the same starting point.
- Unix was developed at Bell Labs starting in 1969 — the epoch was set just before that
- January 1 was chosen as a clean calendar boundary
- 1970 rather than 1969 because the implementation used a counter starting from zero
- Every modern OS, language, and protocol inherited this epoch — there is no competing standard
Negative timestamps: dates before 1970
Negative Unix timestamps represent moments before January 1, 1970 00:00:00 UTC. Most modern 64-bit systems support them correctly, which is useful for historical data, birth dates, archival records, and interoperability with systems whose own epochs start earlier than Unix. Older libraries and databases may reject negative values, so historical datasets deserve an explicit compatibility check.
- -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
- -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
- -2208988800 = January 1, 1900 00:00:00 UTC
- JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'
Practical limits of the format
The Unix epoch itself is not the limit; the storage type is. A timestamp stored in a 32-bit signed integer fails much sooner than a timestamp stored in a 64-bit integer, JavaScript number, or native database timestamp type. When evaluating timestamp safety, ask both what unit is used and what numeric type stores it.
- 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
- JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
- 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
- PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE
Other systems' epochs
Unix is not the only epoch used in computing. Other systems defined their own reference points for historical or technical reasons.
- GPS epoch: January 6, 1980 00:00:00 UTC — used by GPS satellites and receivers
- Windows FILETIME: January 1, 1601 00:00:00 UTC — 100-nanosecond intervals
- Apple Cocoa / NSDate: January 1, 2001 00:00:00 UTC
- Excel / Lotus 1-2-3: January 1, 1900 — with a deliberate off-by-one leap-year bug for Lotus compatibility
- FAT filesystem: January 1, 1980 00:00:00 local time
Epoch seconds, milliseconds, microseconds, and nanoseconds
The word timestamp does not always tell you the unit. Unix seconds are common in operating systems and backend languages. Unix milliseconds are common in JavaScript and browser APIs. Microseconds and nanoseconds appear in databases, tracing systems, and high-resolution logs. The unit controls both precision and the number of digits you see.
- Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
- Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
- Microseconds: 1700000000000000 — common in some databases and event pipelines
- Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
- Always document the unit when storing epoch values in APIs, CSV files, and database columns
Epoch time vs UTC vs local time
Epoch time is a count. UTC is the global time standard that defines the reference moment. Local time is a display choice based on a timezone such as America/New_York or Asia/Tokyo. A Unix timestamp does not change when a user travels; only the formatted calendar date and clock time change.
- The same timestamp can display as different local dates in different timezones
- UTC output is best for logs, APIs, and debugging across servers
- Local output is best for calendars, user interfaces, and reports
- Timezone offsets are applied during formatting, not stored inside the Unix timestamp
Epoch time FAQ
- Is epoch time always in seconds?
- The classic Unix timestamp is seconds since 1970-01-01 00:00:00 UTC, but many systems use milliseconds, microseconds, or nanoseconds with the same epoch.
- Can Unix timestamps represent dates before 1970?
- Yes. Negative timestamps represent dates before the Unix epoch, though older libraries and databases may not support them.
- Does a Unix timestamp include a timezone?
- No. A Unix timestamp represents one instant in UTC. Timezone information is used only when converting that instant into a readable local date.
- What is the maximum Unix timestamp?
- It depends on the storage type, not the epoch. A 32-bit signed integer maxes out at 2,147,483,647 (January 19, 2038), while a 64-bit integer or a JavaScript number reaches hundreds of millions of years. See the Year 2038 problem for the details.