What Unix time is
A Unix timestamp counts the number of seconds elapsed since 00:00:00 UTC on 1 January 1970 — the Unix epoch. It is a single integer with no time zone, no locale, and no formatting ambiguity.
That simplicity is exactly why it became the standard for storing and transmitting time. Comparing two timestamps is an integer comparison. Sorting is numeric. Arithmetic is arithmetic. None of the parsing ambiguity of formatted dates applies.
The epoch date is arbitrary — it was chosen for convenience in early Unix development and simply stuck.
Seconds versus milliseconds
This is the most common source of bugs with timestamps. Unix time is defined in seconds, but JavaScript's Date.now() returns milliseconds.
Mixing them produces dates that are wildly wrong — treating a millisecond value as seconds lands you around the year 56,000, while the reverse gives 1970.
A quick heuristic: a 10-digit number is seconds and a 13-digit number is milliseconds, for any date in the current era. This tool detects the difference automatically.
When designing an API, state the unit explicitly in the field name — created_at_ms rather than created_at — and you eliminate a whole category of integration bug.
The 2038 problem
Systems storing Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038. The counter wraps to negative, and the date jumps to December 1901.
This is a genuine issue rather than a curiosity, though its scope is narrower than Y2K. Most modern systems use 64-bit time, which does not overflow for approximately 292 billion years. The remaining risk sits in embedded systems, legacy hardware, and old database schemas — and in systems that already handle dates 15 years ahead, such as mortgages and pensions, where the bug can surface long before 2038.
Time zones and why timestamps avoid them
A Unix timestamp is always UTC. It has no time zone because it represents an instant, not a local reading of a clock.
This is precisely why storing timestamps is safer than storing formatted local times. 2025-03-30 01:30 in Europe is ambiguous — during the daylight saving transition that local time can occur twice or not at all. A timestamp is never ambiguous.
The correct pattern is: store UTC, display local. Convert at the presentation layer using the user's time zone, and keep everything internal in UTC.
One exception is future events tied to local wall-clock time. A meeting at 9am next March should stay at 9am even if the time zone rules change — and they do change, several times a year worldwide. Such events are better stored as a local time plus a zone identifier.
Leap seconds, briefly
Unix time deliberately ignores leap seconds. It assumes every day has exactly 86,400 seconds, which occasionally means the counter repeats or skips a value when a leap second is inserted.
This makes Unix time technically discontinuous, but it keeps date arithmetic simple — a day is always 86,400 seconds. For virtually all applications that trade-off is correct. Systems requiring true continuity, such as some scientific and financial infrastructure, use TAI instead.
Major platforms typically handle leap seconds by “smearing” them — spreading the adjustment across many hours so no clock ever jumps.
Frequently asked questions
What is a Unix timestamp?
The number of seconds since 00:00:00 UTC on 1 January 1970. It is a single integer with no time zone, which makes comparison, sorting, and arithmetic straightforward.
How do I tell seconds from milliseconds?
A 10-digit number is seconds and a 13-digit number is milliseconds for any date in the current era. JavaScript's Date.now() returns milliseconds, which is a frequent source of bugs.
What is the year 2038 problem?
Systems storing Unix time in a signed 32-bit integer overflow on 19 January 2038, wrapping to a date in 1901. Modern 64-bit systems are unaffected, but embedded devices and legacy schemas remain at risk.
Should I store dates as timestamps or formatted strings?
Store UTC timestamps and format at display time. Local time strings are ambiguous across daylight saving transitions. The exception is future events tied to wall-clock time, which need a local time plus a zone identifier.