DevToolsmith

Unix Timestamp Converter

Paste a Unix timestamp to see it as a date in UTC and your local time, or pick a date to get its timestamp. Seconds, milliseconds, microseconds and nanoseconds are detected automatically from the number of digits.

Runs 100% in your browser — nothing is uploaded

Current Unix time… ms

Read as seconds (from the number of digits).

UTC (ISO 8601)
2026-01-01T00:00:00.000Z
Your local time
2025年12月31日星期三 GMT-7 17:00:00
Relative
now
Unix time (ms)
1767225600000
Unix time (s)
1767225600
RFC 2822 / HTTP date
Thu, 01 Jan 2026 00:00:00 GMT
SQL (UTC)
2026-01-01 00:00:00

What is Unix time?

Unix time counts the seconds since the Unix epoch, 1 January 1970 at 00:00:00 UTC. Because it is just a number, it is easy to store, compare and sort, and it means the same instant everywhere. Time zones only come in when you display it. That is why APIs, log files, JWT claims like exp and databases use it so widely.

Seconds, milliseconds, microseconds or nanoseconds?

Different platforms count in different units. For present-day dates, the number of digits gives it away:

UnitDigitsExample (2026-01-01 UTC)Used by
Seconds101767225600Unix tools, Python, PHP, Go Unix(), JWT, most SQL databases
Milliseconds131767225600000JavaScript Date.now(), Java, Elasticsearch, Prometheus
Microseconds161767225600000000PostgreSQL internals, Python datetime precision, some logs
Nanoseconds191767225600000000000Go UnixNano(), InfluxDB line protocol

If a converted date lands in January 1970 or tens of thousands of years in the future, the unit is wrong. Use the unit buttons above to override the automatic guess.

Get the current Unix timestamp

// JavaScript (milliseconds → seconds)
Math.floor(Date.now() / 1000)

# Python
import time; int(time.time())

// Go
time.Now().Unix()

// Java
Instant.now().getEpochSecond()

# Bash
date +%s

-- PostgreSQL
SELECT extract(epoch FROM now())::bigint;

-- MySQL
SELECT UNIX_TIMESTAMP();

Convert a Unix timestamp to a date

// JavaScript: Date wants milliseconds
new Date(1767225600 * 1000).toISOString()   // "2026-01-01T00:00:00.000Z"

# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1767225600, tz=timezone.utc)

// Go
time.Unix(1767225600, 0).UTC()

# Bash (GNU date / macOS)
date -u -d @1767225600
date -u -r 1767225600

-- PostgreSQL
SELECT to_timestamp(1767225600);

-- MySQL
SELECT FROM_UNIXTIME(1767225600);

Things that trip people up

  • Time zones. A timestamp has none. datetime.fromtimestamp(ts) in Python without tz= returns the server’s local time, which changes when the code moves to a server in another zone.
  • Precision. JavaScript numbers lose precision above 253, so 19-digit nanosecond timestamps can’t be stored exactly in a Number. Use BigInt or keep them as strings.
  • Negative values. Dates before 1970 are negative timestamps. -86400 is 31 December 1969.
  • 2038. Signed 32-bit timestamps run out at 2147483647 (19 January 2038, 03:14:07 UTC). The converter warns you when a timestamp is past that point.

Frequently asked questions

What is a Unix timestamp?

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds since 00:00:00 UTC on 1 January 1970, the Unix epoch. It is the same everywhere in the world at a given moment, so it has no time zone. 1767225600, for example, is 2026-01-01 00:00:00 UTC.

Is my timestamp in seconds or milliseconds?

Count the digits. Timestamps for dates between 2001 and 2286 have 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. JavaScript’s Date.now() and Java’s System.currentTimeMillis() return milliseconds; Unix tools, Python’s time.time() and most databases use seconds. The converter detects this automatically.

Why does my converted date show 1970?

You probably treated a seconds timestamp as milliseconds, which divides it by 1000 and lands in January 1970. In JavaScript, new Date(1767225600) is wrong; use new Date(1767225600 * 1000).

What is the Year 2038 problem?

Systems that store Unix time as a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. One second later the value overflows to a negative number, i.e. December 1901. Modern 64-bit systems are unaffected, but old embedded devices, file formats and database columns (such as MySQL’s TIMESTAMP type) still have the limit.

Does Unix time include leap seconds?

No. Unix time assumes every day has exactly 86,400 seconds, so leap seconds are not counted, and a timestamp doesn’t map one-to-one to atomic time (TAI). For almost all applications this doesn’t matter. Leap seconds are also due to be abolished by 2035.