Unix Timestamp Converter

What Is a Unix Timestamp? The Backbone of System Time

A Unix timestamp (also called Unix time, POSIX time, or Epoch time) is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC — a fixed reference point known as the Unix Epoch. This moment was chosen as the "birth" of Unix time, and every timestamp counts forward (or backward) from it.

Why is this useful? Because a timestamp is timezone-independent. 1716220800 always means May 20, 2024 at 08:00:00 UTC — whether you're in New York, London, or Tokyo. This makes Unix timestamps the universal language for:

• Storing dates in databases without worrying about timezones
• Comparing dates across distributed systems
• Calculating time differences (just subtract one integer from another)
• Logging events in a machine-friendly format

The Unix Epoch: Timestamp Zero

The Unix Epoch (timestamp 0) corresponds to Thursday, January 1, 1970, 00:00:00 UTC. In New York local time (UTC-5) that is Wednesday, December 31, 1969, 19:00:00. Negative timestamps represent dates before 1970 — for example, -315619200 is January 1, 1960.

Seconds vs. Milliseconds: Two Important Variants

Two variants of Unix timestamps are in common use across different programming ecosystems:

Unix Timestamp in Seconds (10-digit integer)

• Example: 1716220800
• Range: -2147483648 (year 1901) to 2147483647 (year 2038) on 32-bit systems
• Used by: Unix/Linux system calls, Python time.time(), PHP time(), Go time.Now().Unix(), PostgreSQL EXTRACT(EPOCH)

Unix Timestamp in Milliseconds (13-digit integer)

• Example: 1716220800000
• Used by: JavaScript Date.now(), Java System.currentTimeMillis(), C# DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()

This converter auto-detects the unit. A 10-digit integer is treated as seconds; 13-digit as milliseconds.

How to Convert Timestamps in Your Favorite Language

JavaScript (Browser & Node.js)

// Unix seconds → Date object
const seconds = 1716220800;
const date = new Date(seconds * 1000);
console.log(date.toISOString()); // "2024-05-20T08:00:00.000Z"

// Current time → Unix seconds
const nowSeconds = Math.floor(Date.now() / 1000);

// Current time → Unix milliseconds
const nowMs = Date.now();

// Format timestamp as local date string
const localString = new Date(seconds * 1000).toLocaleString();

Python 3

from datetime import datetime, timezone

# Timestamp (seconds) → UTC datetime
timestamp = 1716220800
dt_utc = datetime.fromtimestamp(timestamp, tz=timezone.utc)
print(dt_utc)  # 2024-05-20 08:00:00+00:00

# Current time → Unix seconds
now_seconds = int(datetime.now(timezone.utc).timestamp())

# Datetime object → timestamp
dt = datetime(2024, 5, 20, 8, 0, 0, tzinfo=timezone.utc)
ts = int(dt.timestamp())

PHP

// Timestamp → formatted date
$timestamp = 1716220800;
echo date('Y-m-d H:i:s', $timestamp);  // 2024-05-20 08:00:00
echo date('c', $timestamp);             // ISO 8601: 2024-05-20T08:00:00+00:00

// Date string → timestamp
echo strtotime('2024-05-20 08:00:00');  // 1716220800

// Current time → timestamp
$now = time();

SQL (PostgreSQL / MySQL)

-- PostgreSQL: Timestamp → date
SELECT to_timestamp(1716220800);           -- 2024-05-20 08:00:00+00

-- PostgreSQL: Current time → Unix seconds
SELECT EXTRACT(EPOCH FROM NOW())::bigint;

-- MySQL: Timestamp → datetime
SELECT FROM_UNIXTIME(1716220800);          -- 2024-05-20 08:00:00

-- MySQL: Current time → Unix timestamp
SELECT UNIX_TIMESTAMP();

Command Line (Linux / macOS)

# Current time → Unix timestamp
date +%s

# Timestamp → human-readable date (UTC)
date -u -d @1716220800

# Convert a specific date to timestamp
date -d "2024-05-20 08:00:00" +%s

Go

// Unix seconds → Time
seconds := int64(1716220800)
t := time.Unix(seconds, 0)
fmt.Println(t.UTC()) // 2024-05-20 08:00:00 +0000 UTC

// Current time → Unix seconds
nowSeconds := time.Now().Unix()

// Current time → Unix milliseconds
nowMs := time.Now().UnixMilli()

Java

// Timestamp seconds → Instant
long seconds = 1716220800L;
Instant instant = Instant.ofEpochSecond(seconds);
System.out.println(instant); // 2024-05-20T08:00:00Z

// Current time → Unix seconds
long nowSeconds = Instant.now().getEpochSecond();

// Current time → Unix milliseconds
long nowMs = Instant.now().toEpochMilli();

The Year 2038 Problem (Y2K38) — What You Need to Know

Many older systems (including some Linux kernels, embedded devices, and legacy databases) store Unix timestamps as a 32-bit signed integer. The maximum value for a 32-bit signed integer is 2,147,483,647.

That specific number corresponds to January 19, 2038 at 03:14:07 UTC. One second later, at 2,147,483,648, the integer overflows to -2,147,483,648 — which represents December 13, 1901. Date calculations break catastrophically on affected systems.

Is this still a problem today? 64-bit systems are safe, and most modern software is fixed. Linux switched to 64-bit time_t in 2020 for 32-bit architectures. PostgreSQL, MySQL 8+, Python 3, Node.js, Go, and Java 8+ all use 64-bit integers internally. If you maintain older routers, IoT devices, or industrial controllers, verify their timestamp handling before 2038.

ISO 8601 vs. RFC 2822: Two Standards for Date Strings

ISO 8601 (International Standard)

Format: YYYY-MM-DDTHH:mm:ss.sssZ (UTC) or with offset YYYY-MM-DDTHH:mm:ss±hh:mm

ISO 8601 strings sort lexicographically — alphabetical order equals chronological order. This makes them ideal for filenames, database keys, API responses, and log files. Supported natively by every modern programming language and used in JSON APIs, HTML5 <time> elements, and JavaScript's toISOString().

RFC 2822 (Email & HTTP Standard)

Format: Mon, 20 May 2024 08:00:00 +0000

Required for email Date: headers (SMTP), HTTP Date and Last-Modified headers, and RSS/Atom feeds. More human-readable but more verbose. Use ISO 8601 for new APIs unless a specific protocol demands RFC 2822.

Common Pitfalls & Best Practices

Pitfall 1: Confusing Seconds with Milliseconds

This is the #1 mistake developers make. JavaScript Date.now() returns milliseconds, but most backend APIs expect seconds. A 10-digit timestamp used as milliseconds produces a date ~49 years in the past.

const seconds = Math.floor(Date.now() / 1000);  // ✓ seconds
const ms = Date.now();                            // ✓ milliseconds

Pitfall 2: Timezone Assumptions

A Unix timestamp is always UTC. When you convert it to a local date, the hour/minute values change based on your timezone. Never assume a timestamp represents "local time" without explicit conversion.

Pitfall 3: Leap Seconds Are Ignored

Unix time treats every day as exactly 86,400 seconds. Leap seconds are silently ignored, meaning Unix time drifts from true astronomical time by about 27 seconds as of 2024. For most applications this is irrelevant.

Best Practice: Always Use UTC for Storage

Store timestamps as integers (seconds or milliseconds) in your database. Convert to local time only at display time in the frontend. This avoids countless timezone bugs in distributed systems.

Pro Tips for Developers

1. Store timestamps as integers — Use bigint in PostgreSQL/MySQL 8+. Avoid storing timestamps as strings; comparisons are slower and indexing is less efficient.
2. Always use UTC in backend logic — Convert to local time only at the very last moment (frontend display). This avoids timezone mix-up bugs.
3. Be explicit about units — Document whether your API returns seconds or milliseconds. Name variables created_at_seconds or expires_at_ms.
4. Add ISO 8601 strings to logs — Include a human-readable ISO date next to the integer in application logs. Your future self will thank you.
5. Test edge cases — Always test with timestamp 0 (1970-01-01), negative timestamps (pre-1970 dates), and the Y2K38 boundary (2147483647).
6. Use well-tested libraries — For complex date manipulations (timezones, recurring events, relative formatting), use Luxon (JavaScript), Pendulum (Python), or Carbon (PHP).
7. Use this converter for debugging — When you see a mysterious integer like 1728000000 in an API response, paste it here to instantly see the human date.

Summary: When to Use Each Format

Use Case	Recommended Format
Database storage (primary key)	Unix seconds (integer)
Database storage (human readable)	ISO 8601 UTC (string)
API responses	Unix seconds OR ISO 8601 UTC
JavaScript frontend	Unix milliseconds
Log files	ISO 8601 UTC (sortable & readable)
Email headers	RFC 2822
HTTP headers	RFC 2822 or IMF-fixdate
User-facing display	Local date string (user's timezone)
Cron / scheduling	Unix seconds (ease of arithmetic)

Frequently Asked Questions

What is a Unix timestamp used for in real-world applications?

Unix timestamps are everywhere: database timestamps (created_at, updated_at), JWT token expiration (exp claim), log file names, cache invalidation, API rate limiting windows, session timeouts, and distributed system coordination.

Why is 1970-01-01 the Unix Epoch?

The earliest versions of Unix in the early 1970s needed a convenient, recent date to start counting. January 1, 1970 was chosen because it was the start of a new decade and fit within early hardware limitations. It has since become an industry standard.

How do I get the current Unix timestamp in my browser's console?

Open Developer Tools (F12) and type Math.floor(Date.now() / 1000) for seconds, or Date.now() for milliseconds. You can also click the "Use Current Time" button in this converter.

Why does my timestamp conversion show the wrong date?

Most likely a seconds/milliseconds mismatch. If your 10-digit timestamp is accidentally treated as milliseconds, the date will be off by about 49 years. Also verify your local timezone offset if you're comparing UTC output to a local time expectation.

What is the maximum valid timestamp in JavaScript?

JavaScript Date objects can represent timestamps from approximately -8.64e15 to +8.64e15 milliseconds (about ±285,000 years from 1970). For practical purposes, any date within a reasonable human-scale range is safe.

How do I convert a Unix timestamp to a human-readable date in Excel?

For a Unix timestamp in seconds, use the formula: =(A1/86400)+DATE(1970,1,1). Then format the cell as a date/time. For milliseconds: =((A1/1000)/86400)+DATE(1970,1,1).

Do Unix timestamps account for leap seconds?

No. POSIX time explicitly ignores leap seconds. Every day is treated as exactly 86,400 seconds. Unix time drifts from true astronomical time by about 27 seconds as of 2024. Most applications don't need sub-second astronomical accuracy, so this is rarely a problem.

What is the difference between timestamp and datetime in databases?

A timestamp (integer) stores the exact moment in UTC, independent of timezone. A datetime (string/object) stores a wall-clock date and time without timezone information. Use timestamps for logs, analytics, and any system spanning multiple timezones. Use datetime only when the original timezone must be preserved.

How do I generate a timestamp for a specific date in the past or future?

In this converter, type any date string (e.g., "July 4, 1776", "2050-01-01") in the input field. The tool automatically converts it to the correct Unix timestamp. In code, use your language's date parsing functions — Date.parse() in JS, strtotime() in PHP, or datetime.fromisoformat() in Python.

What does "relative time" mean in this tool?

Relative time shows how far the selected timestamp is from the current moment — for example, "2 days ago" or "in 3 hours". This is useful for displaying "last seen", "expires in", or "posted X time ago" labels in user interfaces.

Can I use negative timestamps for dates before 1970?

Yes. Negative timestamps represent dates before the Unix Epoch. For example, timestamp -315619200 is January 1, 1960. Most modern programming languages support negative timestamps, though some older embedded systems may not.

Why does the "Live" button keep updating the timestamp every second?

Live mode automatically updates the input to the current Unix timestamp every second. It is useful for monitoring the real-time epoch counter or for demonstrations. Click "Live" again to stop updating.