How do I know if a timestamp is in seconds or milliseconds?

Check digit count. Seconds timestamps are 10 digits. Milliseconds timestamps are 13 digits. If greater than 9,999,999,999 it is milliseconds. Dates in 1970 or 2554 indicate the wrong unit.

Why does JavaScript use milliseconds instead of seconds?

JavaScript Date was designed with sub-second precision for animations and performance. Always divide by 1000 when passing Date.now() to systems expecting seconds.

How do I convert a timestamp to a specific timezone?

JavaScript: date.toLocaleString('en-US', { timeZone: 'America/New_York' }). Python: use zoneinfo module. PostgreSQL: to_timestamp(ts) AT TIME ZONE 'America/New_York'.

What is the maximum Unix timestamp?

32-bit: 2,147,483,647 = January 19, 2038 (Year 2038 Problem). 64-bit (modern systems): effectively unlimited. Legacy 32-bit systems storing timestamps need auditing.

Unix Timestamp to Date – Convert Epoch Time

A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on January 1, 1970. It is the most common way to store and transmit time values in software because it is a single integer, timezone-independent, and trivially sortable. Converting it to a readable date is a task that comes up constantly — in logs, API responses, database queries, and debugging sessions.

Convert any timestamp instantly Paste a Unix timestamp to see UTC, local time, ISO 8601, and relative time.

Open Timestamp Converter →

The Seconds vs Milliseconds Problem

Before converting, you need to know whether your timestamp is in seconds or milliseconds. This is the most common source of timestamp bugs. A seconds timestamp is 10 digits long until November 2286. A milliseconds timestamp is 13 digits. A quick rule: if your timestamp is greater than 9999999999, it is almost certainly in milliseconds.

JavaScript's Date object uses milliseconds internally. Most other languages and systems use seconds. This mismatch is why you see dates in the year 2554 — a seconds timestamp passed to a JavaScript function that expects milliseconds.

Converting in JavaScript

// Seconds timestamp → Date
const ts = 1716239022;
const date = new Date(ts * 1000);  // multiply by 1000 for ms

// Milliseconds timestamp → Date
const tsMs = 1716239022000;
const date2 = new Date(tsMs);  // no multiplication needed

// Format as readable string
date.toUTCString()      // "Mon, 20 May 2024 21:03:42 GMT"
date.toISOString()      // "2024-05-20T21:03:42.000Z"
date.toLocaleString()   // locale-dependent local time

// Get current timestamp
Math.floor(Date.now() / 1000)  // seconds
Date.now()                      // milliseconds
      

Converting in Python

from datetime import datetime, timezone

ts = 1716239022

# UTC datetime
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt)  # 2024-05-20 21:03:42+00:00

# ISO 8601 format
print(dt.isoformat())  # 2024-05-20T21:03:42+00:00

# Local time (use with caution — depends on system timezone)
dt_local = datetime.fromtimestamp(ts)

# Current timestamp
import time
int(time.time())        # seconds
int(time.time() * 1000) # milliseconds
      

Converting in SQL

-- PostgreSQL
SELECT to_timestamp(1716239022);
SELECT to_timestamp(1716239022) AT TIME ZONE 'UTC';
SELECT to_timestamp(1716239022)::text;

-- MySQL
SELECT FROM_UNIXTIME(1716239022);
SELECT FROM_UNIXTIME(1716239022, '%Y-%m-%d %H:%i:%s');

-- SQLite
SELECT datetime(1716239022, 'unixepoch');
SELECT datetime(1716239022, 'unixepoch', 'localtime');

-- SQL Server
SELECT DATEADD(second, 1716239022, '1970-01-01');
      

Command Line

# Linux/macOS
date -d @1716239022            # Linux
date -r 1716239022             # macOS

# Get current timestamp
date +%s

# Python one-liner
python3 -c "from datetime import datetime,timezone; print(datetime.fromtimestamp(1716239022, tz=timezone.utc))"
      

Common Pitfalls

Forgetting to multiply by 1000 in JavaScript is the most common bug — you get a date in 1970 or the year 2554 depending on which direction the error goes. Always confirm whether your timestamp is seconds or milliseconds before converting.

Timezone confusion is the second most common issue. new Date(ts * 1000) in JavaScript creates a UTC moment, but .toString() and .toLocaleString() display it in local time. .toISOString() and .toUTCString() always show UTC. In Python, datetime.fromtimestamp() without a timezone argument returns local time — always pass tz=timezone.utc for predictable results in server code.

Frequently Asked Questions

How do I know if a timestamp is in seconds or milliseconds?: Check the number of digits. A seconds timestamp is 10 digits until November 2286. A milliseconds timestamp is 13 digits. If your timestamp is greater than 9,999,999,999, it is almost certainly milliseconds. If converting gives you a date in 1970 or 2554, you have the wrong unit.
Why does JavaScript use milliseconds instead of seconds?: JavaScript's Date object was designed with sub-second precision for animations and performance measurement — applications where 1-second resolution is insufficient. This decision predates the widespread use of Unix timestamps in web APIs and has caused a persistent mismatch with most other systems. Always divide by 1000 when passing a JavaScript Date.now() result to a system expecting seconds.
How do I convert a timestamp to a specific timezone?: Unix timestamps are always UTC — timezone is only applied at display time. In JavaScript: date.toLocaleString('en-US', { timeZone: 'America/New_York' }). In Python: use pytz or the zoneinfo module (Python 3.9+). In PostgreSQL: to_timestamp(ts) AT TIME ZONE 'America/New_York'. Our Timestamp Converter shows both UTC and your local timezone automatically.
What is the maximum Unix timestamp?: For 32-bit signed integers: 2,147,483,647, which corresponds to January 19, 2038 — the Year 2038 Problem. For 64-bit integers (used by all modern systems): the maximum is effectively unlimited at billions of years from now. If you are working with legacy systems that store timestamps as 32-bit integers, the 2038 limit is a real concern worth auditing.

Unix Timestamp to Date