Docspira

Unix Timestamp / Epoch Converter

Convert Unix timestamps to dates and dates to Unix timestamps. Everything runs locally in your browser; nothing you enter is sent to Docspira.

Current Unix Timestamp

—

Timestamp → Date

Unit

UTC —
Local —
ISO 8601 —

Date → Timestamp

Interpret as

Unix seconds —
Unix milliseconds —

Nothing you enter here is sent to Docspira. Learn more.

About Unix timestamps

A Unix timestamp counts seconds (or milliseconds) since 1970-01-01T00:00:00Z and represents a single instant; it has no timezone of its own. UTC and Local above are two different readings of that same instant; "Local" uses your browser's timezone. Auto-detects seconds vs. milliseconds by digit count (10 digits or fewer is seconds, 11+ is milliseconds); switch to a manual unit if that guess is wrong. Converting a local date/time on a daylight-saving-time transition day can hit a wall-clock time that never happened or happened twice; this tool reports that rather than guessing.

What this tool does

Convert Unix timestamps into readable dates and back.

Epoch, Unix time, POSIX time: same thing

They are three names for one number: the count of seconds since 1970-01-01 00:00:00 UTC, the "Unix epoch". Strictly, the epoch is the starting moment and the timestamp is the count since then, but "epoch time", "Unix time", "POSIX time" and "Unix timestamp" are used interchangeably. The converter above accepts any of them.

Seconds or milliseconds? Count the digits

For any date between 2001 and 2286, the digit count tells you the unit:

Digits Unit Example Typical source
10 seconds 1790380800 Unix/Linux, PHP time(), Python int(time.time()), most databases, JWT exp/iat
13 milliseconds 1790380800000 JavaScript Date.now(), Java System.currentTimeMillis(), many JSON APIs
16 microseconds 1790380800000000 Python time.time_ns() // 1000, PostgreSQL internals
19 nanoseconds 1790380800000000000 Go time.Now().UnixNano(), Python time.time_ns()

The classic bug: feeding milliseconds into something that expects seconds gives a date tens of thousands of years in the future; feeding seconds into something that expects milliseconds gives a date in January 1970. If a converted date lands in 1970, you almost certainly have a unit mismatch.

Get the current timestamp in your language

Language Seconds Milliseconds
JavaScript Math.floor(Date.now() / 1000) Date.now()
Python int(time.time()) int(time.time() * 1000)
PHP time() (int) round(microtime(true) * 1000)
Java Instant.now().getEpochSecond() System.currentTimeMillis()
Go time.Now().Unix() time.Now().UnixMilli()
C# DateTimeOffset.UtcNow.ToUnixTimeSeconds() DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()
Bash date +%s date +%s%3N (GNU date)
PostgreSQL extract(epoch from now())::bigint (extract(epoch from now()) * 1000)::bigint
MySQL UNIX_TIMESTAMP() ROUND(UNIX_TIMESTAMP(NOW(3)) * 1000)

Convert a timestamp to a date in code

Language Timestamp (seconds) to date
JavaScript new Date(ts * 1000).toISOString()
Python datetime.fromtimestamp(ts, tz=timezone.utc)
PHP gmdate('c', $ts)
Java Instant.ofEpochSecond(ts)
Go time.Unix(ts, 0).UTC()
Bash date -u -d @1790380800 (GNU) or date -u -r 1790380800 (macOS)
PostgreSQL to_timestamp(1790380800)
MySQL FROM_UNIXTIME(1790380800)

Timezone traps

A Unix timestamp has no timezone: it's one instant, the same everywhere on Earth. Timezones only appear when you turn it into a wall-clock date, which is why the converter shows both UTC and your local time.

The trap is on the way back. In JavaScript, Date.parse("2026-09-26") is read as UTC midnight, but Date.parse("2026-09-26T12:00:00") (no Z, no offset) is read as local time. The same code gives different timestamps on a server in UTC and on a laptop in São Paulo. Always include Z or an offset like -03:00 when you build a timestamp from a date string.

Useful reference timestamps

Timestamp UTC date Why it matters
0 1970-01-01 00:00:00 The epoch
-86400 1969-12-31 00:00:00 Negative values are valid: dates before 1970
1000000000 2001-09-09 01:46:40 First 10-digit timestamp
2147483647 2038-01-19 03:14:07 Largest value in a signed 32-bit integer (the "Year 2038 problem")
10000000000 2286-11-20 17:46:40 First 11-digit timestamp in seconds

The Year 2038 problem. Systems that store Unix time in a signed 32-bit integer overflow one second after 2147483647 and wrap to December 1901. Modern 64-bit systems are not affected, but old embedded devices, some file formats and database columns declared as 32-bit INT still are.

ISO 8601 in 30 seconds

2026-09-26T12:00:00Z is the ISO 8601 form the converter outputs. The T separates date and time, and Z means UTC. An offset replaces the Z for other zones: 2026-09-26T09:00:00-03:00 is the same instant. ISO 8601 strings sort correctly as plain text, which is one reason APIs prefer them to localized formats like 09/26/2026.

FAQ

What is the current Unix timestamp?

It's shown live at the top of this page and updates every second. You can copy it with one click.

How do I convert epoch to a human-readable date?

Paste the timestamp into "Timestamp → Date" above. The unit is detected automatically from the number of digits, and you get UTC, your local time and ISO 8601.

Why is my converted date in 1970?

Your number is in seconds but is being read as milliseconds (or the value is 0 or very small). Switch the unit to Seconds.

Does Unix time count leap seconds?

No. Unix time assumes every day has exactly 86,400 seconds and ignores leap seconds, so it isn't a true count of elapsed SI seconds. For almost every application this doesn't matter.

Is a Unix timestamp the same in every timezone?

Yes. The number is identical everywhere at the same moment. Only its conversion to a local date and time depends on the timezone.

Before you start

Check whether the source uses seconds or milliseconds, and select the timezone that matches the system you are diagnosing.

Privacy

This tool runs in your browser; the text or file you choose is not uploaded for processing. Read the privacy details.