One number for all of time
A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds. Right now it is a 10-digit number somewhere north of 1,700,000,000. It is the lingua franca of time in software: databases, APIs, logs, and file systems all store moments as this single integer because it is unambiguous, timezone-free, and trivially sortable.
Why an integer beats a date string
Comparing two moments is just comparing two numbers — no parsing, no "is March 3 before April 1?" ambiguity, no timezone mix-ups. "Add one day" is "+86400 seconds." That simplicity is why the date calculator and nearly every backend converts dates to timestamps internally before doing arithmetic.
The 2038 problem
Many 32-bit systems store the timestamp as a signed 32-bit integer, whose maximum is 2,147,483,647. That value corresponds to 19 January 2038, 03:14:07 UTC. One second later the number overflows and wraps to a negative value — dates suddenly read as 1901. This is the "Y2K38" bug: any old 32-bit device (embedded systems, legacy servers) that still uses a signed 32-bit timestamp will misbehave. Modern 64-bit systems pushed the limit trillions of years out, but the legacy fleet is the risk.
Converting back
To turn a timestamp into a human date, multiply out the seconds: 86400 per day, 3600 per hour, 60 per minute. Online tools and the date calculator do this instantly. The reverse — "what timestamp is next Monday at noon?" — is equally common when debugging logs: find the moment, grab its integer, and query the database with a clean numeric range.
Practical takeaways
- Store time as UTC timestamps; convert to local time only at the display layer.
- When you see a 10-digit number in a log, suspect a timestamp and convert it.
- If you maintain old 32-bit systems, audit their time handling before 2038.