Unix Timestamp Converter — Epoch to Date, Milliseconds, Batch & Countdown (Complete Guide 2026)

If you have ever debugged an API response and found a number like 1741996800 sitting in a field called created_at, or tried to figure out what 1741996800000 means in a JavaScript log, you have encountered a Unix timestamp. They are everywhere in software — in database columns, API JSON, log files, JWT tokens, cookies, and operating system metadata. The free Unix Timestamp Converter gives you five tools in one: epoch-to-date conversion, date-to-timestamp, batch converter for multiple timestamps at once, duration calculator between two timestamps, and a live countdown to any target timestamp — all running instantly in your browser.

This guide covers the full picture: what Unix time actually is and why it exists, the seconds vs milliseconds confusion that trips up almost every developer at least once, timezone gotchas, language-specific conversion code, the Year 2038 problem, and how to use each of the five converter tabs.

What Is a Unix Timestamp — The Real Explanation

A Unix timestamp is a single integer: the number of seconds (or milliseconds in modern variants) that have passed since 00:00:00 UTC on January 1, 1970. That reference point is called the Unix epoch. The timestamp 0 means exactly midnight UTC on January 1, 1970. The timestamp 1741996800 means 1,741,996,800 seconds after that moment.

Why 1970? Because that is when Unix was being developed at Bell Labs, and the developers needed a simple, unambiguous way to store time. They chose a recent, round date as the reference point. It was a practical engineering decision, not a deep philosophical choice — and it has persisted for over 50 years because the simplicity of a single integer for time turned out to be extremely useful.

The key insight is that a Unix timestamp is timezone-independent. It always counts from UTC. When you say timestamp 1741996800, that is the same absolute moment in time whether you are in New York, Mumbai, Tokyo, or London. The local time you display it as varies by timezone, but the timestamp itself is unambiguous. This is why databases store times as timestamps: store once in UTC, display in any local timezone at read time.

Compare this to storing "March 15, 2026 at 6:00 PM" — which timezone? Is that 6:00 PM IST, EST, UTC? You don't know without additional context. A timestamp has no such ambiguity. 1741996800 is a specific, exact moment, period.

Seconds vs Milliseconds — The Confusion That Causes Real Bugs

This is the single most common Unix timestamp mistake and it causes real production bugs. Classic Unix timestamps count in seconds. Modern systems increasingly count in milliseconds. The difference is a factor of 1,000 — and confusing the two produces dates that are wildly wrong.

The quick identification rule: count the digits. A current timestamp in seconds is 10 digits. In milliseconds it is 13. If you see 13 digits and treat them as seconds, you get a date in the year 57,000. If you see 10 digits and treat them as milliseconds, you get a date in January 1970. Both are obviously wrong, which makes this bug easy to catch — but only if you check.

JavaScript's Date.now() returns milliseconds. Python's time.time() returns seconds (as a float, with the decimal part being the sub-second fraction). When a JavaScript frontend sends a timestamp to a Python backend, or vice versa, the unit mismatch has to be handled explicitly. This is an extremely common cross-language bug.

Unix Timestamp Conversion Code — Every Major Language

JavaScript / Node.js

// Current timestamp
const nowSeconds = Math.floor(Date.now() / 1000);   // 10-digit seconds
const nowMs      = Date.now();                        // 13-digit milliseconds

// Timestamp → Date
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString());                      // "2026-03-15T00:00:00.000Z"
console.log(date.toLocaleString("en-IN", { timeZone: "Asia/Kolkata" }));

// Date → Timestamp
const ts = Math.floor(new Date("2026-03-15").getTime() / 1000);

Python

import time
from datetime import datetime, timezone

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

# Timestamp → datetime (UTC)
dt_utc   = datetime.fromtimestamp(now, tz=timezone.utc)

# Timestamp → datetime (IST)
from zoneinfo import ZoneInfo
dt_ist   = datetime.fromtimestamp(now, tz=ZoneInfo("Asia/Kolkata"))

# datetime → timestamp
ts = int(datetime(2026, 3, 15, 0, 0, 0, tzinfo=timezone.utc).timestamp())

SQL

-- MySQL / MariaDB
SELECT FROM_UNIXTIME(1741996800);                  -- seconds → datetime
SELECT UNIX_TIMESTAMP('2026-03-15 00:00:00');      -- datetime → timestamp

-- PostgreSQL
SELECT to_timestamp(1741996800);                   -- seconds → timestamptz
SELECT EXTRACT(EPOCH FROM '2026-03-15'::timestamptz);  -- date → timestamp

-- SQLite
SELECT datetime(1741996800, 'unixepoch');          -- seconds → datetime
SELECT strftime('%s', '2026-03-15');               -- date → timestamp

PHP

// Current timestamp
$now = time();                // seconds
$nowMs = round(microtime(true) * 1000);  // milliseconds

// Timestamp → date
echo date('Y-m-d H:i:s', 1741996800);     // local timezone
echo gmdate('Y-m-d H:i:s', 1741996800);   // UTC

// Date → timestamp
$ts = strtotime('2026-03-15');
$ts = mktime(0, 0, 0, 3, 15, 2026);       // month, day, year

Go

package main
import (
    "fmt"
    "time"
)

// Current timestamp
nowSeconds := time.Now().Unix()
nowNanos   := time.Now().UnixNano()

// Timestamp → time.Time
t := time.Unix(1741996800, 0)
fmt.Println(t.UTC().Format(time.RFC3339))

// time.Time → timestamp
ts := time.Date(2026, 3, 15, 0, 0, 0, 0, time.UTC).Unix()

Bash / Shell

# Current timestamp
date +%s

# Timestamp → human date (Linux)
date -d @1741996800

# Timestamp → human date (macOS/BSD)
date -r 1741996800

# Human date → timestamp (Linux)
date -d "2026-03-15" +%s

The Timezone Trap — Why Timestamp Bugs Are Often Timezone Bugs

Timestamps are UTC by definition. The bug happens at conversion time, when developers forget to specify which timezone they want the human-readable result in.

In JavaScript, new Date(1741996800000).toString() gives the date in the browser's local timezone — which will be different for every user in a different timezone. In a Node.js backend, it gives the server's timezone, which may be UTC on a cloud instance, or US/Eastern on a developer's machine, or Asia/Kolkata on another. If you need a consistent output timezone, always specify it explicitly:

// Always explicit
new Date(1741996800 * 1000).toLocaleString("en-US", { timeZone: "UTC" });
new Date(1741996800 * 1000).toLocaleString("en-IN", { timeZone: "Asia/Kolkata" });

In Python, datetime.fromtimestamp() without a timezone argument uses the system's local timezone — again, inconsistent across machines. Always pass tz=timezone.utc or a specific ZoneInfo object.

The rule that eliminates 90% of timezone bugs: store UTC, display local. All timestamps in your database should be UTC. All API responses should include the timezone or use UTC. All display conversion should happen in the UI layer with explicit timezone handling. Never store a timestamp as a local time — it becomes ambiguous the moment the server's timezone changes or the data is used in a different timezone.

Unix Timestamps in Common Contexts

JWT Tokens (exp, iat, nbf claims)

JSON Web Tokens use Unix timestamps (in seconds) for three standard claims. iat (issued at) is the timestamp when the token was created. exp (expiration) is when it expires — authentication fails after this timestamp. nbf (not before) is when the token becomes valid. If you decode a JWT and see an exp value, paste it into the converter to see when it actually expires as a human date.

HTTP Headers

HTTP's Last-Modified, Expires, and If-Modified-Since headers use HTTP date format (RFC 7231), not Unix timestamps. However, caching headers like Cache-Control: max-age use seconds from the current time — a Unix duration, not an absolute timestamp. Cookies use Unix timestamps in their Expires attribute in some implementations.

Log Files

Server logs, application logs, and system logs frequently include Unix timestamps for compact, sortable time records. A log line like [1741996823] ERROR: connection timeout needs the converter to become human-readable during debugging. The batch converter tab is specifically useful here — paste a column of log timestamps and convert all of them at once.

Database Columns

PostgreSQL's TIMESTAMP and TIMESTAMPTZ types store timestamps internally as microseconds since epoch. MySQL's TIMESTAMP type stores as a 32-bit Unix timestamp (seconds) — meaning it has the Year 2038 problem. MySQL's DATETIME type does not have this limitation. SQLite stores everything as text or real numbers, and typically uses Unix timestamps as integers for time data.

REST APIs and JSON

Most modern REST APIs return timestamps in one of three formats: Unix seconds (integer), Unix milliseconds (integer), or ISO 8601 string (2026-03-15T00:00:00Z). The converter handles Unix seconds and milliseconds directly. For ISO 8601 strings, convert to a timestamp with the Date-to-Timestamp tab by entering the date and time from the string.

The Year 2038 Problem — Explained Simply

A 32-bit signed integer can store values from −2,147,483,648 to 2,147,483,647. In Unix timestamps (seconds), the maximum positive value (2,147,483,647) corresponds to January 19, 2038, at 03:14:07 UTC. One second later, the integer overflows — wrapping from the maximum positive value to the most negative value (−2,147,483,648), which represents December 13, 1901. Any software storing Unix timestamps in a 32-bit signed integer will experience this as a sudden jump back 136 years.

Modern 64-bit systems are not affected. A 64-bit signed integer can represent timestamps up to approximately 292 billion years from epoch. Most modern databases, operating systems, and programming languages already use 64-bit timestamps. The risk is in legacy embedded systems (industrial equipment, old networking hardware), some 32-bit Linux systems, and old databases with 32-bit TIMESTAMP columns (particularly MySQL's TIMESTAMP type, which is 4 bytes). If you are building systems intended to store dates past 2038, use DATETIME in MySQL, BIGINT for timestamps, or PostgreSQL's TIMESTAMP type.

The Five Tools in the Unix Timestamp Converter

Tab 1: Epoch to Date

Paste any Unix timestamp (seconds or milliseconds — the tool auto-detects based on digit count). Select the target timezone from a dropdown covering all standard IANA timezones. Get the full date, time, day of week, and ISO 8601 string. Also shows the timestamp in the other unit (if you entered seconds, shows milliseconds too, and vice versa). Live mode shows the current timestamp updating every second.

Tab 2: Date to Epoch

Enter a date and time using a date picker or type it manually. Select the timezone of the input time (since the same clock time has a different timestamp depending on timezone). Get the corresponding Unix timestamp in both seconds and milliseconds. Useful when writing a database query, setting a JWT expiration time, or constructing an API request that requires a timestamp parameter.

Tab 3: Batch Converter

Paste a list of timestamps, one per line. Select seconds or milliseconds. Choose target timezone. The tool converts all of them simultaneously and outputs the results in a table with the original timestamp and human-readable date side by side. Useful for log analysis, database export review, and any situation where you have a column of timestamps that need to be human-readable.

Tab 4: Duration Calculator

Enter two timestamps (start and end). Get the difference expressed in days, hours, minutes, and seconds. Also shows the total in each unit independently (total hours, total minutes, total seconds). Useful for calculating how long an event or session lasted based on start and end timestamps from logs or a database.

Tab 5: Countdown Timer

Enter a future Unix timestamp. The tool counts down in real time — days, hours, minutes, seconds remaining until that moment. Useful for checking when a JWT token, a session, a sale, or a deadline expires, by pasting the expiration timestamp and watching the countdown.

Common Timestamp Problems and Solutions

Final Thoughts

Unix timestamps are one of those foundational concepts in software development that seem obscure until you start debugging a date-related bug at 11 PM and realise they are in absolutely everything. Once you understand what they are — a count of seconds since January 1, 1970 UTC — most timestamp-related bugs become obvious. It is always either the wrong unit (seconds vs milliseconds) or the wrong timezone applied at conversion time.

The conversion code snippets in this guide cover the cases that come up repeatedly in real development: JavaScript frontend passing timestamps to Python backends, SQL queries filtering by date range using timestamp columns, JWT expiration checks, log file analysis. Keep the patterns bookmarked — they come up more often than you'd expect.

When you need a quick conversion without opening a code editor, the free Unix Timestamp Converter has all five tools ready: epoch-to-date, date-to-epoch, batch conversion, duration calculation, and countdown — all in one place, no account, instant results.