TL;DR: A Unix timestamp is the number of seconds since midnight UTC on 1 January 1970. Logs and APIs use it because it is unambiguous and timezone-free. The two things that catch people out are telling seconds apart from milliseconds, and forgetting that the raw number is always UTC until you convert it to a local zone.
When you are comparing entries across servers, a plain integer is easier to reason about than a formatted date — there is no timezone, no locale, and no daylight-saving ambiguity. But that same rawness is why a stray timestamp can be misread.
Why timestamps start in 1970
The Unix epoch is midnight UTC on 1 January 1970, chosen by the early Unix developers at Bell Labs as a simple, fixed reference point. Every Unix timestamp is just the count of seconds elapsed since that moment, which makes arithmetic — "how long between these two events?" — a plain subtraction.
Seconds or milliseconds?
This is the single most common mistake when reading logs. A rule of thumb: if the value has more than 11 digits (greater than about 10¹¹), it is almost certainly in milliseconds. A current timestamp in seconds is around 1.7 billion (ten digits); the same instant in milliseconds is around 1.7 trillion (thirteen digits). Feed a millisecond value into a seconds-based parser and you'll land tens of thousands of years in the future.
The timestamp is always UTC
A Unix timestamp encodes an absolute instant, not a local wall-clock time. To display it for a human you apply a timezone: the same number is "14:30 in London" and "09:30 in New York". Converting in both directions cleanly means being explicit about which zone you mean — a good converter uses the standard IANA timezone database and the Intl.DateTimeFormat API so the offset (including daylight saving) is correct for the date in question.
ISO 8601 for anything you store or share
When a timestamp has to be human-readable and still machine-safe, use ISO 8601: 2024-03-15T14:30:00.000Z. The T separates date and time and the Z denotes UTC. It sorts correctly as plain text and removes the seconds-vs-milliseconds guesswork for the next person who reads it.
The year 2038 note
Systems that store the timestamp as a signed 32-bit integer overflow on 19 January 2038. Most modern platforms have moved to 64-bit time, but it is worth knowing when you meet an old system or a fixed-width database column.
A practical workflow
- Copy the raw value from your log or API response.
- Paste it into the Timestamp Converter, which auto-detects seconds vs milliseconds and renders the date in your chosen zone.
- Convert both events you're comparing to the same zone (or keep both in UTC) before you subtract.
- Store or share the result as ISO 8601 to avoid re-introducing ambiguity. Pair it with the Character Counter if you're tidying a log excerpt for a ticket.
Common mistakes to avoid
- Mixing seconds and milliseconds in the same comparison.
- Assuming a raw timestamp is already in local time.
- Comparing two events rendered in different timezones.
- Shipping fixed-width 32-bit time fields that can't survive 2038.