Web & encoding · 5 min read
Timestamp converter: epoch time without the guesswork
Unix time is the number of seconds since 1970-01-01T00:00:00 UTC — a single integer that every system understands and almost every developer has misread at least once. A timestamp converter turns that integer into something a human can check and back again, which is usually the fastest way to answer the question every log investigation starts with: when did this actually happen?
Updated
Seconds or milliseconds: the bug that keeps happening
Ten digits is seconds; thirteen is milliseconds. Get it wrong and the date lands in 1970 or thousands of years from now — an error that is instantly recognisable once you have seen it, which is exactly why it is worth recognising. JavaScript’s `Date.now()` returns milliseconds while most server languages and databases store seconds, so the boundary between a browser and an API is where the mistake is usually made.
1760000000 → 2025-10-09 09:33:20 UTC (seconds)
1760000000000 → 2025-10-09 09:33:20 UTC (milliseconds)
UTC is the truth; local time is a presentation choice
An epoch value is unambiguous because it is UTC by definition. The confusion appears when you display it: the same instant is a different wall-clock time in every timezone, and a support ticket that says “it happened at 3pm” is only useful with a timezone attached. Store and transmit epoch or ISO 8601 UTC, convert to local time for display, and always include the zone in anything a human reads.
Where timestamps show up in real work
- Log lines — the fastest way in is converting the epoch column to readable dates before you read for meaning.
- API responses — `created_at`, `expires_at` and cache headers, all more useful once converted.
- JWT claims — `exp` and `iat` are epoch seconds, which is why an expiry check is one subtraction.
- Database rows — comparing a stored epoch against now is arithmetic; comparing it against “last Tuesday” needs a conversion.
A timestamp without a timezone is a bug waiting for a reader. Printed dates belong in ISO 8601 with an explicit offset, such as 2025-10-09T09:33:20Z.
The 2038 boundary
Signed 32-bit seconds since the epoch run out on 2038-01-19. Systems built on that storage — including older MySQL columns and 32-bit time_t platforms — cannot represent later dates, and the failure mode is a wrap into 1901 rather than an error. If you are designing anything intended to outlive the next decade, store 64-bit integers or a native date type now; the migration only gets harder later.
Convert both ways, in the browser
The YamlBox timestamp converter accepts seconds or milliseconds, shows UTC and local interpretations side by side with ISO 8601 output, and goes the other way from a date back to an epoch. It runs entirely client-side, so timestamps from production logs never leave your machine.
Timestamp Converter — frequently asked questions
Why does my timestamp show a 1970 date?
Almost always a unit mismatch: milliseconds were interpreted as seconds, or the value is zero because a field was never populated. Multiply or divide by 1000 as appropriate — the difference between ten and thirteen digits is the whole diagnosis.
What is the difference between epoch time and ISO 8601?
They describe the same instant. Epoch is an integer in UTC seconds, compact and perfect for arithmetic and storage; ISO 8601 is a readable string with an offset, better for humans, logs and APIs that must stay legible.
Do Unix timestamps include timezones?
No — an epoch value is always UTC. Only its rendering has a timezone, which is why converting to a local date requires knowing which zone the reader is in, and why two developers can disagree about the same timestamp while both being correct.
Tools mentioned in this post
Keep reading
6 min read
JWT decoder: what is inside a token, and what is not
Use a JWT decoder to inspect a token’s header, payload and expiry — and understand why decoding is not verifying, with the claim checks behind most 401s.
5 min read
URL encoding: when to escape, and when you are breaking things
URL encode and decode correctly — reserved characters, plus versus %20, encodeURI versus encodeURIComponent, and the double-encoding bugs behind broken links.