Convert Unix timestamps to readable dates and dates back to timestamps, in any time zone. See the current Unix time live.
Current Unix time
…
Dates are shown in this time zone, and the date you enter on the right is read in it. Unix timestamps themselves are always in UTC.
NinjaFunction's Unix Timestamp Converter turns epoch time into a readable date, and a date into a Unix timestamp, in seconds. It detects seconds, milliseconds, microseconds and nanoseconds for you, works in any time zone, and shows the current Unix time live. Copy the result as a local date, UTC, ISO 8601 or a relative time such as 3 hours ago. Everything runs in your browser, so nothing you enter is sent to a server.
Unix time counts the seconds since the Unix epoch: 1 January 1970 at 00:00:00 UTC. It is used in databases, log files, APIs and almost every programming language, because one number is simpler to store, sort and compare than a written date.
The same timestamp means the same moment everywhere. A server in India and one in Canada both read 1700000000 as the same instant, and each only changes how it shows the local clock time.
| Timestamp | Date and time (UTC) | Why it matters |
|---|---|---|
0 | 1 Jan 1970, 00:00:00 | The Unix epoch |
86400 | 2 Jan 1970, 00:00:00 | Exactly one day later |
1000000000 | 9 Sep 2001, 01:46:40 | One billion seconds |
1700000000 | 14 Nov 2023, 22:13:20 | A handy example value |
2147483647 | 19 Jan 2038, 03:14:07 | The largest 32-bit value (Year 2038 problem) |
The same moment can be written with different units. The number of digits tells you which one you have:
| Digits | Unit | Example | Often used in |
|---|---|---|---|
| 10 | Seconds | 1700000000 | Databases, Python, PHP, Linux |
| 13 | Milliseconds | 1700000000000 | JavaScript, Java |
| 16 | Microseconds | 1700000000000000 | Some databases and logs |
| 19 | Nanoseconds | 1700000000000000000 | Go, high-precision tools |
| Language | Seconds since the epoch |
|---|---|
| JavaScript | Math.floor(Date.now() / 1000) |
| Python | int(time.time()) |
| PHP | time() |
| Java | Instant.now().getEpochSecond() |
| C# | DateTimeOffset.UtcNow.ToUnixTimeSeconds() |
| Go | time.Now().Unix() |
| Ruby | Time.now.to_i |
| MySQL | UNIX_TIMESTAMP() |
| PostgreSQL | EXTRACT(EPOCH FROM now()) |
| Bash | date +%s |
Need a unique ID rather than a time? Try the UUID Generator, whose version 7 IDs also contain a timestamp, or decode the expiry time inside a token with the JWT Decoder.
Older systems store Unix time in a 32-bit signed number. The largest value it can hold is 2,147,483,647, which is 19 January 2038 at 03:14:07 UTC. One second later the number overflows and wraps to a negative value, which would read as a date in 1901. Modern systems use 64-bit numbers, which last for hundreds of billions of years, so the problem mostly affects very old software and embedded devices.
A Unix timestamp is the number of seconds that have passed since 1 January 1970 at 00:00:00 UTC. That starting moment is called the Unix epoch. Because it is just one number, it is an easy way for computers to store and compare dates.
Count the digits. A timestamp with 10 digits, such as 1700000000, is in seconds. One with 13 digits, such as 1700000000000, is in milliseconds. JavaScript and Java often use milliseconds, while most databases and command-line tools use seconds. This tool detects the unit for you, and you can also pick it yourself.
No. A timestamp is the same number everywhere in the world, because it always counts from the epoch in UTC. Only the date and clock time you read from it change with the time zone.
Yes. Negative numbers are moments before 1 January 1970. For example, -86400 is 31 December 1969 at 00:00:00 UTC.
Some older systems store the timestamp as a 32-bit signed number, which can only count up to 2,147,483,647. That moment is 19 January 2038 at 03:14:07 UTC. After it, the number overflows and the date can jump back to 1901. Systems that use 64-bit numbers do not have this limit.
If the timestamp is in cell A1 and is in seconds, type =A1/86400+DATE(1970,1,1) in another cell, then format that cell as a date and time. For milliseconds, divide by 86400000 instead.
No. All conversions are done in your browser. Nothing you type is sent or stored.