Guide

How to Convert a Unix Timestamp to a Date (and Back)

A practical, copy-paste guide to turning a Unix timestamp into a readable date — and a date back into a timestamp — in JavaScript, Python, Linux, and SQL.

Last updated June 22, 2026

A Unix timestamp — also called epoch time, Unix time, or sometimes a Linux timestamp — is just the number of seconds since 1 January 1970, 00:00:00 UTC. A value like 1700000000 looks opaque, but it maps to one exact moment in time. This guide shows how to convert that number into a date you can read, and how to go back the other way. If you want the answer right now, try it instantly with the converter — paste a value and see the date in UTC and your local zone. For the background on what these numbers are, see What Is a Unix Timestamp?

Seconds or milliseconds? Count the digits

Before converting, check the unit — getting this wrong is the most common mistake. Unix timestamps are traditionally counted in seconds, but many platforms (notably JavaScript) use milliseconds. For any date in the current era the quickest tell is the length:

• 10 digits → seconds, e.g. 1700000000
• 13 digits → milliseconds, e.g. 1700000000000

Both of those point to the same instant; the millisecond value is just 1000× larger. If a tool expects seconds and you hand it milliseconds (or vice versa), your date will land in 1970 or thousands of years away. The timestamp converter auto-detects the unit, but it helps to know the rule.

The idea behind the conversion

Conceptually a conversion is simple: take the count of seconds and add it to the epoch (1970-01-01 00:00:00 UTC). 1700000000 seconds after the epoch is 2023-11-14 22:13:20 UTC. The number itself carries no time zone — it is always UTC — so the only real work is formatting that instant in whatever zone you want to display. Every example below produces that same moment.

Convert a Unix timestamp to a date

Here is the same conversion of 1700000000 (seconds) in four common environments. Each prints 2023-11-14 22:13:20 UTC.

JavaScript

// JavaScript's Date works in MILLISECONDS, so multiply seconds by 1000.
new Date(1700000000 * 1000).toISOString();
// "2023-11-14T22:13:20.000Z"

// Already have milliseconds? Pass them straight in:
new Date(1700000000000).toUTCString();
// "Tue, 14 Nov 2023 22:13:20 GMT"

Python

from datetime import datetime, timezone

# Pass tz=timezone.utc to get a clear, UTC-based result.
datetime.fromtimestamp(1700000000, tz=timezone.utc)
# datetime.datetime(2023, 11, 14, 22, 13, 20, tzinfo=datetime.timezone.utc)

Linux / macOS (the date command)

# GNU date (most Linux distros) — the -u flag prints UTC:
date -u -d @1700000000
# Tue Nov 14 22:13:20 UTC 2023

# BSD date (macOS) uses -r instead of -d @:
date -u -r 1700000000
# Tue Nov 14 22:13:20 UTC 2023

SQL

-- PostgreSQL
SELECT to_timestamp(1700000000);          -- 2023-11-14 22:13:20+00

-- MySQL (returns the result in the session time zone)
SELECT FROM_UNIXTIME(1700000000);         -- 2023-11-14 22:13:20

-- SQLite
SELECT datetime(1700000000, 'unixepoch'); -- 2023-11-14 22:13:20

Convert a date back to a Unix timestamp

The reverse direction takes a date and returns the seconds since the epoch. Watch the units (JavaScript hands you milliseconds) and be explicit about UTC.

// JavaScript — divide milliseconds by 1000 for seconds
Math.floor(Date.parse('2023-11-14T22:13:20Z') / 1000);  // 1700000000
Math.floor(Date.now() / 1000);                           // current timestamp

# Python — build an aware datetime, then .timestamp()
from datetime import datetime, timezone
int(datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc).timestamp())  # 1700000000

# Linux / macOS
date -u -d '2023-11-14 22:13:20' +%s   # 1700000000  (GNU)
date +%s                                # current timestamp

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '2023-11-14 22:13:20Z')::bigint;  -- 1700000000

Mind the time zone

The timestamp is UTC, but the date you display usually is not — and that mismatch is the second-most-common bug. The same instant 1700000000 is 2023-11-14T22:13:20Z in UTC, yet 2023-11-15T07:13:20+09:00 in Tokyo. A few traps to remember:

• Python's datetime.fromtimestamp(ts) uses your machine's local zone unless you pass tz=timezone.utc.
• The date command and SQL functions like FROM_UNIXTIME render in the session/system zone — add -u or convert explicitly for UTC.
• Parsing a string without an offset is interpreted as local time, shifting the result.

When in doubt, try it instantly with the converter: it shows UTC and your local zone together, plus any major time zone, so an off-by-a-few-hours result is obvious.

Common mistakes to avoid

• Mixing seconds and milliseconds. A result in 1970 (or far in the future) almost always means a ×1000 or ÷1000 is missing.
• Forgetting UTC vs. local. An answer that is off by a whole number of hours is a time-zone problem, not a wrong timestamp.
• Trusting a 32-bit field past 2038. Signed 32-bit timestamps overflow on 19 January 2038 — see the year 2038 problem.

Related: What Is a Unix Timestamp? A Developer's Guide — the basics of epoch time, the 1970 origin, and the 2038 problem.

Convert a timestamp now →