Every developer meets 1757328000 sooner or later — staring from a log file, an API response, or a database column — and thinks: is that... Tuesday? Unix timestamps are the lingua franca of machine time: one integer, no timezones, no formats, no ambiguity. Except they are completely unreadable to humans, and the ecosystem has three competing dialects that cause an endless drip of off-by-hours bugs. Ten minutes from now, all three will make sense.
Seconds, Milliseconds, and the Bug That Never Dies
Classic Unix time counts seconds since 1970-01-01 UTC — ten digits until the year 2286. JavaScript's Date.now() returns milliseconds — thirteen digits. Passing one where the other is expected shifts dates by factors of a thousand: your "meeting tomorrow" lands in 1970 or the year 55,000. The single most common timestamp bug in web development, full stop. Our converter auto-detects by digit length, so pasting either form just works — but now you will recognize which is which on sight: 10 digits, seconds; 13, milliseconds.
ISO 8601: The Human-Readable Upgrade
2026-09-08T12:00:00Z carries the same instant in a form humans can squint at: date, T separator, time, and that crucial trailing Z meaning UTC. Prefer ISO in logs, APIs you design, and anywhere humans debug — future-you at 2am will be grateful. The Z (or explicit +02:00 offset) is load-bearing: a bare 2026-09-08 12:00 means noon in whosever timezone parses it, which is how "works on my machine" time bugs are born.
UTC vs Local: The Off-By-Hours Playbook
When a displayed time is wrong by exact hours, run this checklist: (1) Was a UTC value formatted as local, or vice versa? (2) Did daylight saving shift underneath a stored local time? (3) Is the server's system timezone what you assume? (4) Did JavaScript's zero-indexed months strike (new Date(2026, 8, 8) is September)? Pasting the value into the converter shows UTC and local side by side — the shift reveals itself instantly.
Timestamp FAQs
What happens in 2038?
Signed 32-bit second-counters overflow in January 2038 (the Y2K38 problem). Modern 64-bit systems, millisecond timestamps, and ISO strings are immune — one more reason new code should avoid 32-bit epoch storage.
Why do identical timestamps show different times on two machines?
Timezone settings differ. The instant is identical; the wall-clock rendering follows each machine's locale. Compare UTC readings to confirm sameness.
Epoch vs ISO for my database?
Native datetime/timestamp columns when the DB offers them (indexing, date math, readability), integers when storing opaque API values verbatim. Never strings without timezone info — that is how data rots.
Staring at a ten-digit number right now? Translate it.
Convert Timestamp Free