Unix Timestamp Converter

What is a Unix Timestamp?

A Unix timestamp (also known as Unix epoch time, POSIX time, or Unix time) is a timekeeping system widely used in programming and computer systems. It represents time as the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a moment known as the Unix Epoch. For example, the timestamp 1700000000 corresponds to November 14, 2023 at 22:13:20 UTC.

The strength of Unix timestamps lies in their simplicity and consistency: a single integer value, independent of any timezone or country-specific date format. This makes them the de facto standard for storing and transmitting time data in databases, APIs, log files, and network protocols. Nearly every programming language has built-in functions to convert between timestamps and human-readable date formats.

This tool helps you convert between Unix timestamps and common date formats such as ISO 8601, RFC 2822, and human-readable representations. All processing happens in your browser — no data is ever sent to a server. You can enter timestamps in seconds (10 digits) or milliseconds (13 digits), and the tool will auto-detect the format.

How Unix Epoch Time Works

The Unix timekeeping system begins at the "zero" moment of 00:00:00 UTC on January 1, 1970. Each second after this point increments the counter by 1. For example: 00:01:00 (one minute after Epoch) has a timestamp of 60, one hour later is 3600 (60 x 60), and one day later is 86400 (24 x 60 x 60).

Moments before the Epoch are represented as negative numbers. For instance, December 31, 1969 at 23:59:59 UTC has a timestamp of -1. Historical events further back have very large negative timestamps — the French Revolution (1789), for example, has a timestamp of approximately -5706153600.

Leap seconds are a special consideration: Unix time does not account for leap seconds — meaning Unix time assumes every day has exactly 86400 seconds. When a leap second is inserted, operating systems handle it in various ways (stepping, smearing, or repeating the timestamp). This means Unix timestamps are not perfectly accurate to astronomical time, but the discrepancy is only a few dozen seconds over 50+ years and does not affect the vast majority of applications.

In practice, most systems use NTP (Network Time Protocol) to synchronize clocks with accurate time servers, ensuring timestamps remain consistent across computers and data centers worldwide.

Timestamp Formats Explained

There are several different formats for representing time, each serving a specific purpose:

• Unix Timestamp: An integer (seconds since Epoch). Simple, compact, ideal for storage and computation. Not directly human-readable.
• ISO 8601: 2026-03-26T14:30:00Z. The international standard, used in RESTful APIs, JSON, and XML. The trailing "Z" denotes UTC; offsets like +07:00 indicate specific timezones.
• RFC 2822: Thu, 26 Mar 2026 14:30:00 +0000. Standard for email headers and HTTP headers. Includes the day name, readable but longer than ISO 8601.
• Millisecond Timestamp: Unix timestamp multiplied by 1000. Used in JavaScript (Date.now()), Java (System.currentTimeMillis()), and many modern APIs. Higher precision.
• Human Readable: "March 26, 2026 2:30 PM". Depends on locale and timezone, should only be used for end-user display.

When designing APIs or databases, always store time in UTC and convert to local timezones only at the display layer. This avoids complex bugs related to DST (Daylight Saving Time) and timezone conversions.

The Year 2038 Problem

The Year 2038 Problem, often called "Y2K38" or the "Unix Millennium Bug," is an integer overflow error that will occur at 03:14:07 UTC on January 19, 2038. At that moment, the number of seconds since the Unix Epoch will reach 2147483647 — the maximum value a signed 32-bit integer can store.

The next second (2147483648) will overflow to a negative value on 32-bit systems, causing clocks to "roll back" to December 13, 1901. This could cause serious failures in time-dependent systems: digital certificates, backup schedules, financial systems, and IoT devices.

The solution: most modern operating systems have already switched to 64-bit integers for storing timestamps. A 64-bit integer can represent time up to approximately 292 billion years in the future — more than sufficient for any conceivable use case. However, many embedded systems, IoT devices, and legacy software still use 32-bit timestamps and need to be updated before 2038.

See related tools: JSON Formatter, Base64 Encoder, and Cron Expression Generator.

Working with Timestamps in Code

Every programming language has its own way of working with Unix timestamps. Here are the most common examples across popular languages:

JavaScript / TypeScript

// Get current timestamp (seconds)
const now = Math.floor(Date.now() / 1000);

// Convert timestamp to Date object
const date = new Date(timestamp * 1000);

// Convert Date to timestamp
const ts = Math.floor(date.getTime() / 1000);

// Format for a specific timezone
date.toLocaleString('en-US', { timeZone: 'America/New_York' });

Python

import time
from datetime import datetime, timezone

# Current timestamp
now = int(time.time())

# Timestamp to datetime
dt = datetime.fromtimestamp(ts, tz=timezone.utc)

# Datetime to timestamp
ts = int(dt.timestamp())

PHP

// Current timestamp
$now = time();

// Timestamp to date string
$date = date('Y-m-d H:i:s', $timestamp);

// Date string to timestamp
$ts = strtotime('2026-03-26 14:30:00');

SQL (MySQL / PostgreSQL)

-- MySQL: timestamp to datetime
SELECT FROM_UNIXTIME(1774544200);

-- PostgreSQL: timestamp to datetime
SELECT to_timestamp(1774544200);

-- MySQL: datetime to timestamp
SELECT UNIX_TIMESTAMP('2026-03-26 14:30:00');

-- PostgreSQL: datetime to timestamp
SELECT EXTRACT(EPOCH FROM timestamp);

Key tip: Always use UTC when storing timestamps in your database. Only convert to local timezones at the display layer (frontend). This helps avoid DST-related bugs and ensures consistency when servers are distributed across multiple geographic regions.