Seconds or milliseconds
A Unix timestamp counts the time elapsed since midnight UTC on 1 January 1970. The catch is that some systems count in seconds and others in milliseconds.
- Seconds — Unix commands, time functions in PostgreSQL and MySQL, the
expandiatclaims in a JWT, most REST APIs - Milliseconds — JavaScript’s
Date.now(), Java’sSystem.currentTimeMillis(), plenty of log pipelines
Mix them up and you land in January 1970 (milliseconds read as seconds) or somewhere in the year 50000 (seconds read as milliseconds). This tool guesses the unit from the magnitude and tells you which way it read the number, so check that line first when a date looks wrong.
The time zone trap
A timestamp has no time zone. It is a single number naming an instant; the zone only appears when that number is turned into text for a human. The same value reads as 4pm in Seoul and 7am in London.
A bug report that says “it failed at 3pm” is therefore missing half the information. Log timestamps or ISO 8601 strings with an offset, and build the human-readable time only at the point of display.
The 2038 problem
Stored in a signed 32-bit integer, a timestamp overflows on 19 January 2038. At that moment the value wraps negative and the date reads as 1901. Modern languages and databases use 64 bits, but if you maintain older embedded firmware or legacy C, the width of that field is worth a look.
Negative values and zero
Negative timestamps point at dates before 1970. They turn up whenever old dates such as birthdays are stored this way, and some libraries handle them poorly.
Zero is midnight UTC on 1 January 1970. When it shows up in real data it is almost never a real time — it is a field that was never initialised.