Unix time: the number that runs everything
Why computers count seconds since 1970, what happens in 2038, and the seconds-vs-milliseconds bug every developer ships once.
5 min read · Reviewed July 2026
Every log line, token expiry, and file modification date on most of the world's computers is secretly the same thing: a count of seconds since midnight UTC, January 1, 1970. No time zones, no daylight saving, no calendar quirks — one integer, ticking upward forever. The date is arbitrary (Unix was born around then and the engineers needed a zero), but the idea is why it won: comparing two moments becomes comparing two numbers.
All the human complexity — zones, DST, leap years — gets applied only at display time, at the edge. Store the number, format at the last moment. Half of all timestamp bugs come from violating that one principle.
The bug you will ship once
Unix time comes in two sizes: seconds (10 digits, what Unix tools and most APIs use) and milliseconds (13 digits, what JavaScript uses). Mix them up and dates land in 1970 (treated ms as seconds) or in the year 56,000-something (treated seconds as ms). Every developer ships this bug exactly once. The converter above auto-detects by digit count, which is also the trick for eyeballing logs: 10 digits seconds, 13 milliseconds.
2038, the quiet deadline
On January 19, 2038, the count exceeds what a signed 32-bit integer holds, and unpatched systems wrap around to 1901. Modern 64-bit systems are safe for 292 billion years — but embedded devices, old databases, and binary file formats with 32-bit timestamp fields linger everywhere, and some are in industrial equipment with 20-year lifespans. It's Y2K's shy sibling: mostly handled, guaranteed to surprise somewhere. If you maintain anything with a 32-bit timestamp in its storage format, your deadline is closer than it feels.