What epoch time actually counts
A Unix timestamp is the number of seconds elapsed since 1 January 1970 00:00:00 UTC, the Unix epoch. It has no timezone, no locale and no ambiguity: the same instant produces the same number everywhere on Earth, which is precisely why it is the format of choice for logs, databases and APIs.
It also, strictly speaking, ignores leap seconds. A Unix timestamp counts days as exactly 86,400 seconds, so during a leap second the clock repeats a value rather than incrementing. For anything short of scientific timekeeping this is irrelevant — but it is why Unix time is not the same as elapsed physical time.
Seconds or milliseconds: the most common bug
Unix and most backend languages use seconds. JavaScript's Date.now() uses milliseconds. Mixing the two is the single most frequent timestamp bug in web development, and the symptom is unmistakable: dates in January 1970, or dates roughly fifty thousand years in the future.
JWT claims (exp, iat, nbf) are specified in seconds. Passing Date.now() directly into an exp claim produces a token that expires around the year 56,000 — and a security review that will not be kind to you.
The quick check is digit count: a current timestamp in seconds has 10 digits, in milliseconds 13. This tool applies that rule automatically, and lets you override it.
The year 2038 problem
Systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038, when the value exceeds 2,147,483,647. The counter wraps to negative, and the date jumps back to December 1901.
Modern 64-bit systems and every mainstream language runtime use wider types and are unaffected — a 64-bit signed count of seconds lasts about 292 billion years. The remaining exposure is in embedded devices, old file formats and database columns explicitly declared as 32-bit integers.
Choosing a format for APIs
Store and transmit instants either as an integer epoch or as ISO 8601 with an explicit offset (2026-08-14T15:30:00Z). Both are unambiguous. What causes incidents is anything else: 08/14/2026 is read as 14 August in the US and rejected elsewhere, and a bare 2026-08-14 15:30:00 with no offset means different instants in different places.
A useful discipline is to keep everything in UTC internally and convert to local time only at the presentation layer. This tool shows both so you can spot the moment where an off-by-a-few-hours error creeps in.