A Unix timestamp counts the time elapsed since 1 January 1970, 00:00:00 UTC (the "epoch"), ignoring leap seconds. It is a single number, so it is easy to store, compare and sort, and it does not depend on time zones.
Seconds, milliseconds, microseconds, nanoseconds
Different systems store the same idea at different precision. You can usually tell which by counting digits for dates near today:
- 10 digits, such as 1700000000: seconds (classic Unix, many databases and APIs).
- 13 digits, such as 1700000000123: milliseconds (JavaScript Date.now(), Java, many APIs).
- 16 digits: microseconds (used by some databases and tracing tools).
- 19 digits: nanoseconds (Go time.UnixNano, logging and tracing systems).
Mixing these up is a classic bug: treating a millisecond value as seconds gives a date tens of thousands of years in the future, and the reverse lands in January 1970.
Pitfalls
- JavaScript numbers hold integers exactly only up to 2^53, so nanosecond timestamps (about 1.7 x 10^18) need BigInt or strings.
- A timestamp is always UTC; the confusion comes when it is displayed. Show the time zone next to local times.
- The "year 2038 problem" affects systems that store seconds in a signed 32-bit integer, which overflows on 19 January 2038.
- Browsers deliberately blur high-resolution clocks, so you rarely get true nanosecond precision from the browser itself.
The converter detects the unit from the number of digits, lets you override it, and keeps all nine fractional digits when you work in nanoseconds.