Unix Timestamp Converter: Epoch Time to Date and Back (2026)

What is a Unix timestamp?

A Unix timestamp (also called epoch time, POSIX time or Unix time) is a single integer that counts the seconds since 00:00:00 UTC on January 1, 1970. That starting point is the Unix epoch.

Because it is one number with no time zone, no daylight-saving rules and no calendar format, it is the standard way computers store and exchange moments in time:

Negative timestamps are valid too: they represent dates before 1970. For example, -86400 is December 31, 1969 at 00:00 UTC.

Seconds vs milliseconds: how to tell them apart

The most common conversion bug: mixing up units. The rule of thumb in 2026 is the digit count:

If you convert a 13-digit value as seconds you'll get a date 56,000+ years in the future. If you convert a 10-digit value as milliseconds you'll land in January 1970. Both are instantly recognizable signs of a unit mismatch — divide or multiply by 1,000 to fix it. This tool auto-detects the unit from the digit count.

Unix timestamp conversion table

Handy reference values (all UTC):

And the arithmetic you use daily:

Get the current timestamp in 10 languages

// JavaScript — Date.now() returns milliseconds!
Math.floor(Date.now() / 1000)   // seconds

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

// PHP
time();

-- MySQL
SELECT UNIX_TIMESTAMP();
-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::int;

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

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

// C#
DateTimeOffset.UtcNow.ToUnixTimeSeconds();

# Ruby
Time.now.to_i

# Bash / Linux
date +%s

// Swift
Int(Date().timeIntervalSince1970)

Convert a timestamp to a date (code)

// JavaScript — multiply seconds by 1000
new Date(1782950400 * 1000).toISOString()
// "2026-07-01T00:00:00.000Z"

# Python — UTC-aware (recommended)
from datetime import datetime, timezone
datetime.fromtimestamp(1782950400, tz=timezone.utc)

-- MySQL
SELECT FROM_UNIXTIME(1782950400);
-- PostgreSQL
SELECT to_timestamp(1782950400);

// PHP
date('Y-m-d H:i:s', 1782950400);   // server time zone
gmdate('Y-m-d H:i:s', 1782950400); // UTC

And the reverse, date to timestamp:

// JavaScript
Math.floor(new Date('2026-07-01T00:00:00Z').getTime() / 1000)

# Python
from datetime import datetime, timezone
int(datetime(2026, 7, 1, tzinfo=timezone.utc).timestamp())

-- MySQL
SELECT UNIX_TIMESTAMP('2026-07-01 00:00:00');

Unix time and time zones

A Unix timestamp is always UTC — it has no time zone of its own. The time zone only appears when you format it for humans:

• Store and exchange in Unix time (UTC). Never store local times in databases.
• Convert to local time only at display time, using the viewer's IANA zone (e.g. America/New_York).
• Remember DST: the same timestamp formats to 19:00 in New York in summer (UTC-4) but 18:00 in winter (UTC-5). The timestamp itself never changes.

Need to see what a timestamp means across cities? Use our time zone converter after converting.

The year 2038 problem

On January 19, 2038 at 03:14:07 UTC the timestamp reaches 2147483647 — the maximum value of a signed 32-bit integer. Systems that still store Unix time in 32 bits will overflow to a negative number and read the date as December 1901.

Modern 64-bit systems are safe for ~292 billion years, but the problem persists in embedded devices, old file formats and legacy databases. If you maintain long-lived systems (contracts, mortgages, certificates expiring after 2038), verify your storage type today.

Common mistakes

• Treating a 13-digit millisecond value as seconds (date lands in year ~58,000).
• Forgetting * 1000 in JavaScript's Date() constructor, which expects milliseconds.
• Using datetime.fromtimestamp() in Python without tz= — it silently applies the server's local zone.
• Storing local wall-clock time in the database instead of epoch/UTC.
• Assuming Unix time counts leap seconds — it doesn't; each day is exactly 86,400 seconds.
• Comparing timestamps from different units (s vs ms) without normalizing first.
• Hard-coding a UTC offset instead of using an IANA time zone name — breaks twice a year with DST.
• Using 32-bit integers for dates beyond January 2038.

Frequently asked questions

Related tools