Practical guide · verified against the real thing
Unix time explained: why computers count seconds from 1970
In one line: The integer clock underneath every API and database: seconds since the epoch, the milliseconds trap, timezones, and the 2038 question.
Ask an API for the time and it will not answer in words. It will hand you a number — something like 1757548800. That is Unix time: the count of seconds elapsed since 1 January 1970, 00:00:00 UTC (the "epoch"), not counting leap seconds. One convention, one integer, the same moment everywhere on Earth — and that last property is the entire point.
Why an integer wins
Human time is a mess of timezones, daylight-saving shifts and calendar quirks; computer time needs to compare, sort and compute durations. An integer does all three trivially: later is bigger, subtraction gives elapsed seconds, and there is exactly one true value to store. Timezones enter only at the display layer — the same timestamp renders as Lagos afternoon, London evening and New York morning, because rendering to a timezone is a presentation choice, never a property of the stored moment. Storing local times instead of timestamps is one of the classic database mistakes precisely because it bakes a presentation choice into the data.
The seconds-vs-milliseconds trap
The number one timestamp bug in web development: some systems (JavaScript's Date.now() most prominently) give milliseconds since the epoch — thirteen digits — while most APIs and databases use seconds — ten digits. Feed milliseconds to a seconds-expecting system and your event lands in the year 57,000. The reliable tell is digit-count, and it is why the timestamp converter on this site auto-detects the unit instead of asking you to guess. When an integration produces dates absurdly in the future, divide by 1000 and check before anything else.
The 2038 question, stated calmly
Systems that store Unix time in a signed 32-bit integer run out of representable seconds on 19 January 2038 — the count overflows the maximum the type can hold. This is the Y2K problem's quieter sibling: modern 64-bit systems are unaffected (the limit recedes by ~292 billion years), and the fix is boring and known — use a 64-bit time type. It matters mainly for old embedded devices and long-lived industrial systems, which is why the date still has a name.
Two honest footnotes for completeness: Unix time officially ignores leap seconds — the moments when Earth's sloppy rotation gets a correction second; they simply don't exist in the count, which occasionally causes minute-scale oddities in systems that care about astronomical precision. And 1970-01-01 itself is why a zero timestamp usually means "unset" in code. When you need to actually convert a value, the converter tool does seconds, milliseconds, local and UTC in one place.
Next