Timestamp Converter

A Unix timestamp is a single number, which is exactly why it is easy to get wrong: a number carries no unit and no time zone, so whoever reads it has to supply both. The two mistakes below account for almost every "the date is wrong" bug, and neither is visible in the number itself.

The 1000x gap between seconds and milliseconds

The same instant is 1700000000 in seconds and 1700000000000 in milliseconds. JavaScript works in milliseconds everywhere — Date.now(), getTime(), new Date(ms) — while many backend systems emit seconds. Mix the two and the error is a factor of a thousand, not a rounding wobble. A seconds value multiplied by 1,000 by mistake becomes a date about 50,000 years out; a milliseconds value handed to a seconds API is truncated and lands in the wrong decade entirely.

The tell-tale symptom is a date of 1970. A ten-digit number read as milliseconds is always in January 1970, because ten-digit milliseconds only reach a few days past the epoch. So when a log line shows 1970-01-20 for something that happened last week, the number was seconds and something treated it as milliseconds. The workbench flags this case explicitly: type a ten-digit value and read the note under the input, which prints both the seconds reading and the 1970 reading so the mismatch is obvious.

Not every timestamp starts at 1970

"Unix time" is an assumption, not a guarantee. Several platforms count from their own epoch, and the offsets are large enough to move a date by decades. Apple's Core Foundation dates count seconds from 1 January 2001. GPS time counts from 6 January 1980 and ignores leap seconds. Windows FILETIME counts 100-nanosecond ticks from 1 January 1601. Read any of those as Unix seconds and you get a plausible-looking but wrong year — the worst kind of wrong, because it does not look broken.

The guard is arithmetic, not trust. If a "seconds" value formats to a year before your product existed, you are probably looking at a different epoch rather than a bad clock. Converting a Core Foundation value to Unix is a single addition of the epoch offset in seconds; the point is to know that the conversion is needed at all, which a number by itself will never tell you.

Time zones are a display problem, not a storage problem

Store instants in UTC and convert only for display. An instant has no time zone; a wall-clock time does. Once you start doing calendar arithmetic in local time you inherit daylight-saving rules, and those rules change. On the spring-forward day the local clock jumps from 02:00 to 03:00, so 02:30 simply does not exist; add "one day" to a wall clock across that boundary and you may land 23 or 25 hours later.

This page formats a single instant in as many zones as you like and never shifts a wall clock, which is why its answers stay correct across transitions. Pick America/New_York as the second zone and convert 1773000000 (8 March 2026) to watch the offset change from -05:00 to -04:00 mid-day. No offset table is consulted: the browser's IANA data answers for the exact instant, which is the only way to be right in a world where governments move their clocks on short notice.

How to verify that this page is offline

Open the developer tools, select the Network panel and clear it, then convert a value and use Batch mode. No request is made — the formatting is pure Intl work and the batch rewrite is a regular expression over your own text. As a second check, switch off your network connection and convert again; everything still works, because the whole tool is the page you already loaded.

How does the tool decide whether a number is seconds or milliseconds?

By digit count. A value of exactly ten digits is read as seconds and a value of thirteen as milliseconds, which covers every modern Unix timestamp: seconds crossed ten digits on 9 September 2001, and milliseconds crossed thirteen digits on the same day. Values that are neither are accepted but flagged, and the batch replacer only rewrites a ten-digit run that lands between 2001 and 2099, so order numbers and commit prefixes are left alone.

Why does a timestamp sometimes show 1970?

Because a millisecond value was read as seconds, or the reverse. A seconds value multiplied by 1,000 by mistake becomes a date roughly 50,000 years in the future, and a millisecond value divided by 1,000 becomes a date in January 1970 — the start of the Unix clock. The page reports both readings whenever a ten-digit value is detected so you can see the mismatch instead of trusting the wrong one.

Which time zone does the page use for my local time?

Whatever your operating system reports for the browser. The page asks Intl.DateTimeFormat for the resolved zone and formats every instant with the browser’s own copy of the IANA time-zone database, so daylight-saving rules are always current. There is no offset lookup service and no hard-coded offset table to go stale.

Can it convert every timestamp inside a log file at once?

Yes. Open Batch mode below the result panel, paste the text, and press Replace timestamps. The replacer only rewrites a standalone run of exactly ten or thirteen digits, and only when ten digits fall inside the 2001–2099 window, so hashes, request ids and version strings survive untouched.

Is the timestamp I paste sent anywhere?

No. Parsing, formatting and the batch rewrite all run in the page using Intl and plain arithmetic. Open the network panel, clear it, and convert a value: no request carries it. The tool also works offline once the page is loaded.