Unix timestamps explained: seconds, milliseconds and 2038

A Unix timestamp is a count of seconds since midnight UTC on 1 January 1970. That is the whole definition, and almost every bug involving them comes from one of two things: the wrong unit, or an assumption about time zones that was never true.

Seconds or milliseconds? Count the digits

For any date in the current era, a timestamp in seconds has ten digits and one in milliseconds has thirteen. That is the fastest check available and it is reliable for roughly the next two centuries.

Getting it wrong has a distinctive signature. A value in seconds interpreted as milliseconds lands in January 1970; the reverse lands tens of thousands of years in the future. If a date looks absurd rather than merely wrong, the unit is almost certainly the cause. JavaScript works in milliseconds, while most databases and APIs use seconds, so conversions cross that boundary constantly.

Timestamps have no time zone

A timestamp identifies an instant, not a wall-clock reading. The same value is 14:00 in London and 09:00 in New York, and neither is more correct. Time zones are a display concern applied at the edge.

This is why the same timestamp appears as two different dates in a database console and an application log: one is rendering in UTC and the other in local time. The stored value is identical. Store instants, convert at the point of display, and the ambiguity disappears.

Leap seconds and the year 2038

Unix time ignores leap seconds by definition — it assumes every day is exactly 86,400 seconds. This makes arithmetic simple and means Unix time is not a perfectly accurate count of elapsed seconds. For almost all software this does not matter.

The 2038 problem does. Systems storing timestamps in a signed 32-bit integer overflow on 19 January 2038 and wrap to 1901. Modern platforms use 64-bit values, but embedded devices, older database columns and file formats can still be affected — and code that computes far-future dates can hit it today.