Unix Timestamp Converter: How to Convert Epoch Time to Human-Readable Dates

If you've ever seen a number like 1711100400 in a database, API response, or log file and wondered what it meant, you've encountered a Unix timestamp. These seemingly random numbers are one of the most universal ways to represent time in software.

This guide explains what Unix timestamps are, why they exist, how to convert them, and how to avoid the subtle bugs they can cause.

What Is a Unix Timestamp?

A Unix timestamp (also called epoch time, POSIX time, or Unix time) is the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC — a moment known as the Unix epoch.

Timestamp:  0           → January 1, 1970 00:00:00 UTC
Timestamp:  1000000000  → September 9, 2001 01:46:40 UTC
Timestamp:  1711100400  → March 22, 2024 15:00:00 UTC
Timestamp:  1774393200  → March 22, 2026 15:00:00 UTC

Right now, as you read this, the Unix timestamp is a 10-digit number somewhere around 1.77 billion. It increments by 1 every second, continuously, without regard for timezones, daylight saving time, or calendar quirks.

Why January 1, 1970?

The Unix operating system was developed at Bell Labs in the late 1960s. When they needed a starting point for their time system, they chose the nearest round date: the start of 1970. It was arbitrary but practical, and it stuck. Every Unix-like system since — Linux, macOS, Android, and countless servers — uses this same epoch.

Why Developers Use Timestamps

Timestamps solve real problems that human-readable dates create:

1. No Timezone Ambiguity

The string "March 22, 2026, 3:00 PM" means different moments depending on whether you're in New York, London, or Tokyo. But 1774393200 means exactly one moment in time, everywhere.

2. Easy Math

Calculating the difference between two dates in human format requires handling months with different lengths, leap years, and timezone transitions. With timestamps, it's subtraction:

const start = 1774393200;  // March 22, 2026 15:00:00 UTC
const end   = 1774479600;  // March 23, 2026 15:00:00 UTC

const differenceInSeconds = end - start;  // 86400
const differenceInHours   = differenceInSeconds / 3600;  // 24

3. Sorting and Comparison

Timestamps are plain numbers. Sorting events chronologically is just sorting numbers — the simplest possible operation for a database or programming language.

4. Storage Efficiency

A Unix timestamp fits in a 32-bit or 64-bit integer. A formatted date string like "2026-03-22T15:00:00.000+05:30" takes 29+ bytes. At scale, this matters.

5. Language Agnostic

Every programming language can work with integers. Timestamps transfer seamlessly between JavaScript, Python, Go, Rust, SQL, and anything else — no parsing ambiguity.

Seconds vs Milliseconds

One of the most common timestamp bugs comes from confusing seconds and milliseconds:

Format	Example	Used By
Seconds (10 digits)	`1774393200`	Unix/Linux, Python, PHP, Ruby, most APIs
Milliseconds (13 digits)	`1774393200000`	JavaScript, Java, some APIs
Microseconds (16 digits)	`1774393200000000`	Some databases, high-precision systems
Nanoseconds (19 digits)	`1774393200000000000`	Go, some logging frameworks

If your converted date shows up as January 1970, you probably passed a seconds-based timestamp to a function expecting milliseconds (or vice versa).

// JavaScript uses milliseconds
new Date(1774393200);      // Wrong! → January 21, 1970
new Date(1774393200 * 1000); // Correct → March 22, 2026
new Date(1774393200000);   // Correct → March 22, 2026

Converting Timestamps

Using the EasyWebUtils Converter

The fastest way to convert timestamps is our Timestamp Converter tool. Enter a Unix timestamp to see the human-readable date, or pick a date to get the timestamp. It handles both seconds and milliseconds and shows results in your local timezone and UTC.

In JavaScript

// Current timestamp (seconds)
const now = Math.floor(Date.now() / 1000);
console.log(now);  // e.g., 1774393200

// Timestamp to date
const date = new Date(1774393200 * 1000);
console.log(date.toISOString());       // "2026-03-22T15:00:00.000Z"
console.log(date.toLocaleString());    // Local format in user's timezone

// Date to timestamp
const ts = Math.floor(new Date('2026-03-22T15:00:00Z').getTime() / 1000);
console.log(ts);  // 1774393200

In Python

import datetime

# Current timestamp
import time
now = int(time.time())
print(now)  # e.g., 1774393200

# Timestamp to date
dt = datetime.datetime.fromtimestamp(1774393200, tz=datetime.timezone.utc)
print(dt)  # 2026-03-22 15:00:00+00:00

# Date to timestamp
dt = datetime.datetime(2026, 3, 22, 15, 0, 0, tzinfo=datetime.timezone.utc)
ts = int(dt.timestamp())
print(ts)  # 1774393200

In SQL

-- PostgreSQL: timestamp to readable date
SELECT to_timestamp(1774393200) AT TIME ZONE 'UTC';
-- Result: 2026-03-22 15:00:00

-- PostgreSQL: date to timestamp
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2026-03-22 15:00:00 UTC');
-- Result: 1774393200

-- MySQL: timestamp to readable date
SELECT FROM_UNIXTIME(1774393200);
-- Result: 2026-03-22 15:00:00

In Bash

# Current timestamp
date +%s
# Output: 1774393200

# Timestamp to date (Linux)
date -d @1774393200
# Output: Sun Mar 22 15:00:00 UTC 2026

# Timestamp to date (macOS)
date -r 1774393200

Timezone Handling

Timezones are the single biggest source of timestamp-related bugs. Here are the rules that prevent them:

Rule 1: Store in UTC

Always store timestamps as UTC (which Unix timestamps inherently are). Convert to local time only when displaying to users.

Rule 2: Convert at the Edges

Your backend, database, and API should all work in UTC. Convert to the user's timezone only in the frontend, at the moment of display:

const timestamp = 1774393200;
const date = new Date(timestamp * 1000);

// Display in different timezones
console.log(date.toLocaleString('en-US', { timeZone: 'America/New_York' }));
// "3/22/2026, 11:00:00 AM"

console.log(date.toLocaleString('en-US', { timeZone: 'Asia/Tokyo' }));
// "3/23/2026, 12:00:00 AM"

console.log(date.toLocaleString('en-US', { timeZone: 'Europe/London' }));
// "3/22/2026, 3:00:00 PM"

Rule 3: Be Explicit About Timezone

Never parse a date string without specifying its timezone. "2026-03-22 15:00:00" without a timezone is ambiguous — different systems will interpret it differently.

// Ambiguous — timezone depends on system settings
new Date('2026-03-22 15:00:00');

// Explicit — always UTC
new Date('2026-03-22T15:00:00Z');

// Explicit — specific timezone offset
new Date('2026-03-22T15:00:00+05:30');

Timestamps in Databases

Choosing between timestamps and datetime types is a common architectural decision.

Unix Timestamp (INTEGER)

CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    name TEXT,
    created_at BIGINT  -- Unix timestamp
);

Pros: Timezone-neutral, efficient storage, easy arithmetic, universal across systems Cons: Not human-readable in raw queries, requires conversion for display

TIMESTAMP / DATETIME

CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    name TEXT,
    created_at TIMESTAMP WITH TIME ZONE
);

Pros: Human-readable, built-in timezone support, native date functions Cons: Timezone handling varies between databases, more complex cross-system transfers

Recommendation

For most applications, use your database's native TIMESTAMP WITH TIME ZONE type. It gives you the best of both worlds: timezone awareness and human readability. Use integer timestamps when you need maximum portability across systems or when working with APIs that expect epoch time.

If you're building APIs that exchange timestamps in JSON payloads, ISO 8601 strings (2026-03-22T15:00:00Z) are the most interoperable format — they're human-readable, unambiguous, and universally parseable.

The Year 2038 Problem

32-bit systems store Unix timestamps as signed 32-bit integers, which max out at:

2,147,483,647 → January 19, 2038, 03:14:07 UTC

One second later, the value overflows to a negative number, which many systems interpret as December 13, 1901. This is called the Y2K38 problem or the Epochalypse.

Who's Affected?

Embedded systems (IoT devices, industrial controllers, automotive)
32-bit databases storing timestamps as integers
Legacy applications that haven't been updated
File systems using 32-bit timestamps

The Fix

Most modern systems have already migrated to 64-bit timestamps, which won't overflow for approximately 292 billion years. If you're writing new code, ensure your timestamp variables use 64-bit integers.

// JavaScript: Numbers are 64-bit floating point — no 2038 problem
new Date(2147483648 * 1000);  // Works fine: January 19, 2038

// But be careful with 32-bit systems or languages

Notable Timestamps

Some timestamps have become part of computing lore:

Timestamp	Date	Significance
`0`	Jan 1, 1970	The Unix epoch
`1000000000`	Sep 9, 2001	"Billion second" milestone
`1234567890`	Feb 13, 2009	Sequential digits celebration
`2000000000`	May 18, 2033	Next "billion" milestone
`2147483647`	Jan 19, 2038	32-bit overflow (Y2K38)

Developers have been known to throw parties at these milestones. The billennium (1000000000) was particularly celebrated.

Common Pitfalls

Mixing Seconds and Milliseconds

The most frequent bug. If your date shows 1970, check your units.

Ignoring Timezones

A timestamp created on a server in UTC and displayed on a client without timezone conversion will show the wrong time for most users.

Using Local Time for Storage

Storing local times instead of UTC leads to ambiguity during daylight saving transitions, when the same local time occurs twice.

Floating Point Precision

JavaScript represents all numbers as 64-bit floats, which can lose precision for very large timestamps. For nanosecond-precision timestamps, use BigInt:

const nanoTimestamp = BigInt("1774393200000000000");

Leap Seconds

Unix time technically doesn't account for leap seconds — it pretends every day is exactly 86400 seconds. In practice, this rarely matters unless you're building systems that need sub-second accuracy across years (GPS, scientific computing).

Timestamps and UUIDs

Both timestamps and UUIDs are used to identify and order events. UUID v7 actually embeds a Unix timestamp in the identifier, giving you both uniqueness and chronological ordering. Generate UUIDs with our UUID Generator.

If you're working with API data that includes timestamps, the JSON Formatter makes it easier to inspect nested payloads, and the Base64 decoder can help decode any encoded timestamp values in authentication tokens.

FAQ

What is the current Unix timestamp?

The Unix timestamp changes every second. To see the current one, visit our Timestamp Converter — it displays the live current timestamp alongside conversion tools. You can also get it programmatically: Date.now() / 1000 in JavaScript or time.time() in Python.

Should I use timestamps or datetime in my database?

For most applications, use your database's native TIMESTAMP WITH TIME ZONE type — it's the most ergonomic and handles timezones correctly. Use integer Unix timestamps when you need portability across heterogeneous systems, when working with APIs that use epoch time, or when you need minimal storage overhead. See the detailed comparison in the "Timestamps in Databases" section above.

How do I handle timezones correctly?

Store everything in UTC. Convert to local time only when displaying to the user. Use libraries like Intl.DateTimeFormat (JavaScript), pytz or zoneinfo (Python), or moment-timezone (legacy JavaScript) rather than manually calculating offsets. Never parse a date string without an explicit timezone.

What happens after the Year 2038 problem?

Systems using 64-bit timestamps (most modern software) are unaffected — they won't overflow for 292 billion years. The risk is with legacy 32-bit systems, especially embedded devices. The industry has been migrating for years, and most critical infrastructure will be updated before 2038. It's a known, solvable problem — unlike Y2K, there's plenty of lead time.

Why do some APIs use milliseconds instead of seconds?

JavaScript's Date.getTime() returns milliseconds, and since JavaScript dominates web development, many web APIs adopted the convention. Java also uses milliseconds natively. The extra precision is occasionally useful for ordering events that happen within the same second. Always check an API's documentation to confirm which unit it uses — getting it wrong produces dates in 1970 or the year 55000.

Convert Timestamps Instantly

Working with Unix timestamps doesn't have to involve mental math or Stack Overflow searches. The EasyWebUtils Timestamp Converter lets you convert between Unix timestamps and human-readable dates instantly, with support for both seconds and milliseconds, timezone display, and live current-time updates. Bookmark it — you'll use it more often than you think.