A Unix timestamp is an integer: the number of seconds elapsed since 00:00:00 UTC on 1 January 1970 up to a given moment. It carries no time zone and no format — it is just a number, and that is exactly what makes it useful: every machine on the planet derives the same number for the same instant, so storing it in a database, putting it in an API response or passing it between systems never turns into an argument about "Beijing time or Tokyo time" or "year-month-day or month-day-year". Render it as a date in the local time zone only when a human has to read it.
So a timestamp itselfhas no time zone. In the phrase "convert this timestamp to Beijing time", the conversion happens at the display step, not at the storage step. The time zone switch above this page changes only how values are displayed and interpreted — one timestamp is the same instant in both zones.
10 digits means seconds, 13 digits means milliseconds — a factor of 1000 apart. This is where things go wrong most often in practice: Java's System.currentTimeMillis()and JavaScript's Date.now() return milliseconds (13 digits), while Unix date +%s, PHP's time()and MySQL's UNIX_TIMESTAMP() return seconds (10 digits). Read milliseconds as seconds and you land somewhere past the year 57000; read seconds as milliseconds and you land in the first days of January 1970.
Telling them apart is easy — count the digits. In this era a second-level timestamp is 10 digits and a millisecond-level one is 13, and that will not change any time soon. This page detects the unit from the digit count and shows what it decided; if your data really is in another unit, just edit the input. You will occasionally meet 16 digits (microseconds) and 19 digits (nanoseconds), mostly from high-precision Go and Python APIs and from distributed tracing systems, and this page recognises those too.
That starting point is called the Epoch, and it comes from the early Unix implementations. There is nothing special about 1970; whoever set the standard simply picked a recent round year, which made it convenient to cover a few decades either side with the 32-bit integers of the day. As Unix spread, the convention was inherited by C, Java, JavaScript, every kind of database and very nearly every network protocol.
The largest number of seconds a signed 32-bit integer can hold corresponds to 19 January 2038, past which it overflows into a negative number — this is the "Year 2038 problem". Modern systems have moved to 64-bit storage and no longer have that ceiling, but old devices, old firmware and protocols that hard-coded a 32-bit field years ago can still be caught out. At the other end, negative timestamps represent moments before 1970; they are perfectly legal and this page supports them.
On the command line, date +%s gives seconds anddate +%s%3N gives milliseconds (Linux; on macOS date does not support %N, so install coreutils and use gdate). In JavaScript it is Date.now() (milliseconds) and Math.floor(Date.now()/1000) (seconds). In Python it is time.time(), which returns floating-point seconds. In Java it is System.currentTimeMillis(). In PHP it is time().
On the database side, MySQL uses UNIX_TIMESTAMP() to read one and FROM_UNIXTIME(ts) to turn it back into a date (note that it renders in the connection's time zone); PostgreSQL uses EXTRACT(EPOCH FROM now()) and to_timestamp(ts). Plenty of people search for this, but what they need is one line of code rather than a web page — copy it and go.
Almost certainly a time zone issue. China is UTC+8, so a timestamp rendered as UTC looks 8 hours earlier than Beijing time. Flip the time zone switch at the top of the page; if the value then matches, that was the cause. Database functions (MySQL's FROM_UNIXTIME, for instance) render in the time zone of the connection session, so a server whose time zone is not set correctly produces the same 8-hour gap.
Count the digits: 10 is seconds, 13 is milliseconds. This page detects it automatically and shows what it decided. If the result lands in the first days of January 1970, seconds were read as milliseconds; if it lands tens of thousands of years from now, milliseconds were read as seconds.
Yes. Moments before 1970 are written as negative timestamps — for example -86400 is 31 December 1969. Just paste one in; no extra setting is needed.
It is taken from this device's system clock and has nothing to do with our servers (every tool on this site runs locally in the browser). If the device clock is off, the value shown here is off by the same amount. If you need an accurate time, synchronise the system clock first.
No. JavaScript stores time in a double-precision float, whose range goes far beyond a 32-bit integer, so this page converts timestamps past 2038 without trouble. What the problem affects is systems that still store time in a signed 32-bit integer.
A timestamp is a number; ISO 8601 is a text format (such as 2026-08-17T12:00:00.000Z). The former is compact and easy to compute with and compare; the latter is directly readable and carries its time zone with it. Both are common in APIs, and this page outputs both forms at once.
No. Conversion uses the browser's built-in Date object — the calculation is purely local and no request is made. Disconnect from the network once the page has loaded and the tool still works. See the Privacy Policy.
Yes. JSON Format shows the structure of the data an API returned, Base64 encode/decode deals with encoding problems, and MD5 and SHA-256 are for computing digests and verifying files.