What is the Unix epoch? Why computers count seconds from January 1, 1970

How this is calculated

The epoch was chosen pragmatically by Unix engineers at Bell Labs in the early 1970s. They needed a round number that was recent enough to keep timestamps small (fitting in a 32-bit signed integer) but far enough in the past to represent dates before the system was written. January 1, 1970, was convenient. The 32-bit signed integer limit (2,147,483,647 seconds) will overflow on January 19, 2038, the Year 2038 problem, which is why modern systems use 64-bit timestamps.

Verdict

The epoch itself was a pragmatic Bell Labs pick (a recent enough round number to fit 32-bit timestamps, far enough back to cover pre-Unix dates) and the integer-as-time model is the elegant win: one number, timezone-independent, sortable, O(1) to compare, supported by every language and database. POSIX defines the day as exactly 86,400 seconds and ignores leap seconds, which keeps the math simple at the cost of a small drift over decades. The 32-bit ceiling hits on January 19, 2038, which is the operational reason modern systems carry 64-bit time_t where the same integer model stretches to roughly 292 billion years in either direction. The principle for storing is the same either way: keep the integer in the database, convert to local time only at the presentation layer, never store local-time strings with implicit timezones.