Unix Timestamp Converter Online — Epoch Time Guide

What Is a Unix Timestamp?

A Unix timestamp (also called epoch time or POSIX time) is a single integer counting the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC — the Unix epoch. The current timestamp as of 2026 is approximately 1,780,000,000.

The epoch itself — why 1970? Unix was being developed at Bell Labs in the late 1960s. 1970 was chosen as the reference point because it was close to when Unix was being designed and made integer arithmetic simple for the dates the system would commonly work with. It was also the start of a decade, making it a clean reference point for a new operating system.

The key advantage of Unix timestamps is that they are timezone-independent. The same integer represents the same instant everywhere on Earth, so two servers in different countries recording “1700000000” agree on exactly which moment that was. The conversion to a human-readable string only happens at display time, using whichever timezone the viewer is in.

This is why timestamps are the standard for logging, event systems, database storage, and any distributed system where consistency across timezones matters. The alternative — storing human-readable strings like “2023-11-14 10:13 PM EST” — creates ambiguity, timezone comparison problems, and sorting issues.

How to Convert a Unix Timestamp

1. Open the Unix Timestamp Converter
2. Select direction: Timestamp → Human to decode a timestamp, or Human → Timestamp to encode a date
3. Choose precision: seconds (10-digit) or milliseconds (13-digit)
4. Enter the timestamp or pick a date, then click Convert
5. The result shows UTC, ISO 8601, your local time, and a relative label
6. Click Use Now to instantly load the current timestamp

Seconds vs Milliseconds: Which Do You Have?

The most common source of confusion with Unix timestamps is the precision. Count the digits:

If your timestamp has 13 digits, divide by 1000 before converting, or switch the converter's precision toggle to milliseconds. The most common mistake: treating a JavaScript millisecond timestamp as seconds — this makes a 2023 date appear to be in the year 55,000 CE.

UTC, Local Time, and ISO 8601

A Unix timestamp converts to three commonly used human-readable formats:

• UTC — Coordinated Universal Time, the global reference. Example: Mon, 15 Jan 2024 14:30:00 GMT
• ISO 8601 — The international standard, always UTC with a Z suffix. Example: 2024-01-15T14:30:00.000Z. Sortable as a string because it is year → month → day → hour → minute → second. Supported universally.
• Local time — Converted to the viewer's browser timezone. The same timestamp shows as 9:30am EST or 2:30pm GMT.

The critical rule: when storing timestamps in a database, always store in UTC (as a Unix timestamp, TIMESTAMPTZ, or ISO 8601 string ending in Z). Convert to local time only when displaying to the user. Storing local time in databases creates timezone arithmetic bugs that are extremely difficult to debug after the fact.

Code Examples

JavaScript / Node.js

// Current timestamp
const nowSeconds = Math.floor(Date.now() / 1000);   // 1700000000
const nowMs = Date.now();                            // 1700000000000

// Timestamp to Date
const d = new Date(1700000000 * 1000);
console.log(d.toISOString());     // "2023-11-14T22:13:20.000Z"
console.log(d.toUTCString());     // "Tue, 14 Nov 2023 22:13:20 GMT"
console.log(d.toLocaleString());  // local timezone string

// Date to timestamp
const ts = Math.floor(new Date('2024-01-15T14:30:00Z').getTime() / 1000);

Python

import time
from datetime import datetime, timezone

# Current timestamp
now = int(time.time())                  # seconds
now_ms = int(time.time() * 1000)        # milliseconds

# Timestamp to datetime (UTC)
dt_utc = datetime.fromtimestamp(1700000000, tz=timezone.utc)
print(dt_utc.isoformat())              # "2023-11-14T22:13:20+00:00"

# Datetime to timestamp
dt = datetime(2024, 1, 15, 14, 30, tzinfo=timezone.utc)
ts = int(dt.timestamp())

# Never use datetime.utcnow() — it returns a naive datetime
# Always use datetime.now(timezone.utc) instead

SQL

-- PostgreSQL: timestamp to Unix
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;
SELECT EXTRACT(EPOCH FROM created_at)::BIGINT FROM orders;

-- PostgreSQL: Unix to timestamp
SELECT TO_TIMESTAMP(1700000000) AT TIME ZONE 'UTC';

-- MySQL: timestamp to Unix
SELECT UNIX_TIMESTAMP(NOW());
SELECT UNIX_TIMESTAMP(created_at) FROM orders;

-- MySQL: Unix to datetime
SELECT FROM_UNIXTIME(1700000000);

-- SQLite: get current Unix timestamp
SELECT strftime('%s', 'now');

Go

import "time"

// Current timestamp
now := time.Now().Unix()        // seconds
nowMs := time.Now().UnixMilli() // milliseconds
nowNs := time.Now().UnixNano()  // nanoseconds

// Timestamp to time.Time
t := time.Unix(1700000000, 0).UTC()
fmt.Println(t.Format(time.RFC3339)) // "2023-11-14T22:13:20Z"

// time.Time to timestamp
ts := time.Date(2024, 1, 15, 14, 30, 0, 0, time.UTC).Unix()

Common Timestamp Issues in Databases

MySQL TIMESTAMP vs DATETIME

MySQL has two date storage types with different behaviors:

• TIMESTAMP: Stored as UTC internally; converted to/from the session timezone on read/write. Range: 1970–2038 (32-bit). Subject to the Year 2038 problem.
• DATETIME: Stored as-is, no timezone conversion. Range: 1000–9999. Not subject to 2038. Does not automatically convert to UTC.

For new applications: use DATETIME columns and store UTC values explicitly, or use BIGINT for Unix timestamps directly.

PostgreSQL TIMESTAMPTZ vs TIMESTAMP

In PostgreSQL, TIMESTAMPTZ (timestamp with time zone) stores values internally in UTC, regardless of input timezone. TIMESTAMP (without time zone) stores the literal value with no timezone information — leading to timezone ambiguity when the application changes timezone settings. Always use TIMESTAMPTZ.

The Year 2038 Problem

32-bit signed integers can hold values up to 2,147,483,647. That timestamp corresponds to January 19, 2038 at 03:14:07 UTC. On systems using a 32-bit integer to store the Unix timestamp, the value will overflow and wrap to a large negative number — causing dates to appear as December 13, 1901.

This affects embedded systems, old 32-bit kernels, and legacy databases usingINT(11) columns for timestamps. All 64-bit systems and modern databases are unaffected — a 64-bit signed integer can represent dates more than 292 billion years into the future.

Common Reference Timestamps