How to Convert a Unix Timestamp to a Date

The fastest way to convert a Unix timestamp to a date is to paste it into a converter that shows you both UTC and local time at once — you can do that free, in your browser, with the Timestamp Converter. In code, the conversion is a single function call: new Date(timestamp * 1000) in JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) in Python, or to_timestamp(ts) in PostgreSQL. The one rule that trips everyone up is knowing whether your number is in seconds or milliseconds before you convert.

This guide covers what a Unix timestamp actually is, the seconds-vs-milliseconds gotcha, UTC versus local time, the 2038 problem, ISO 8601 formatting, and copy-paste examples for JavaScript, Python, and SQL — both directions.

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 00:00:00 UTC on 1 January 1970, not counting leap seconds. That fixed starting point is called the Unix epoch.

For example, the timestamp 1719360000 represents Thursday, 26 June 2026, 00:00:00 UTC. It is just a count of seconds — there is no time zone baked into the number itself. The time zone only matters when you render the number as a date for a human to read.

Storing time as a single integer is convenient because:

• It is unambiguous — one number means exactly one instant, everywhere on Earth.
• It is easy to compare and sort — subtracting two timestamps gives you a duration in seconds.
• It is compact and language-agnostic — every platform knows how to parse an integer.

This is why APIs, log files, databases, JWTs, and cookies overwhelmingly use Unix timestamps under the hood instead of formatted date strings.

Seconds vs. Milliseconds

Here is the single most common source of bugs: not all Unix timestamps use the same unit.

A quick heuristic: count the digits. For any date in the 2020s–2030s, a 10-digit number is seconds and a 13-digit number is milliseconds. If you feed milliseconds into a function expecting seconds, you will land roughly 50,000 years in the future. If you feed seconds into JavaScript’s Date, you will land in January 1970.

Why and When You Need to Convert

You will reach for a timestamp-to-date conversion constantly:

• Debugging logs and APIs — a response says "created_at": 1719360000 and you need to know what day that was.
• Reading JWTs — the exp and iat claims are Unix timestamps; you need to check if a token is expired. (If you’re working with tokens, see how to decode a JWT token.)
• Database forensics — a row’s updated_at column stores epoch seconds and you want it in your local time.
• Scheduling and cron — you computed a “run at” time and want to sanity-check it against the wall clock. (For schedule syntax, see how to create cron expressions.)
• Building features — converting a user’s “expires in 7 days” into a stored timestamp, or rendering “posted 3 hours ago.”

When you just need the answer once, a converter is faster than opening a REPL. When you’re writing code, you need the right function for your language. We’ll cover both.

How to Convert a Unix Timestamp to a Date (Step by Step)

Option 1: Use an Online Converter (Fastest)

1. Open the Timestamp Converter.
2. Paste your number into the input field (for example 1719360000).
3. Read off the result — a good converter shows you both the UTC date and your local-time date side by side, plus the ISO 8601 string.
4. Click to copy whichever format you need.

Everything runs in your browser. Nothing is uploaded to a server, which matters when the timestamp comes from a log line you’d rather not paste into a random website.

To go the other way — from a calendar date back to a timestamp — most converters also accept a date input and hand you the epoch number.

Option 2: Convert in JavaScript

JavaScript’s Date constructor expects milliseconds, so multiply seconds by 1000.

// Input: Unix timestamp in SECONDS
const ts = 1719360000;

const date = new Date(ts * 1000);

date.toISOString();    // "2026-06-26T00:00:00.000Z"  (always UTC)
date.toString();       // local time, e.g. "Wed Jun 25 2026 17:00:00 GMT-0700 (PDT)"
date.toLocaleString(); // formatted for the user's locale

// If your timestamp is already in MILLISECONDS, don't multiply:
const dateMs = new Date(1719360000000);

Going back from a Date to a Unix timestamp:

const now = new Date();

now.getTime();              // milliseconds since epoch, e.g. 1719360000000
Math.floor(now.getTime() / 1000); // seconds since epoch
Date.now();                 // shortcut for current time in milliseconds

Option 3: Convert in Python

Python uses seconds (as a float), and you should pass a time zone explicitly to avoid ambiguity.

from datetime import datetime, timezone

ts = 1719360000

# UTC — recommended for storage and logs
datetime.fromtimestamp(ts, tz=timezone.utc)
# 2026-06-26 00:00:00+00:00

# Local time (uses the machine's configured time zone)
datetime.fromtimestamp(ts)

# ISO 8601 string
datetime.fromtimestamp(ts, tz=timezone.utc).isoformat()
# '2026-06-26T00:00:00+00:00'

Going back from a datetime to a timestamp:

from datetime import datetime, timezone

dt = datetime(2026, 6, 26, tzinfo=timezone.utc)
dt.timestamp()        # 1719360000.0
int(dt.timestamp())   # 1719360000

# Current time as a Unix timestamp
import time
int(time.time())

Avoid the old datetime.utcfromtimestamp() — it returns a naive datetime (no time zone attached), which is a frequent source of off-by-hours bugs. It is deprecated in recent Python versions for exactly this reason.

Option 4: Convert in SQL

Different databases use different functions. Here’s a reference for the common ones, converting epoch seconds to a timestamp:

For millisecond input, scale accordingly — for example PostgreSQL’s to_timestamp(ms / 1000.0), or BigQuery’s TIMESTAMP_MILLIS(ms).

Option 5: Convert on the Command Line

# Linux (GNU date) — convert seconds to a date
date -d @1719360000
# Thu Jun 26 00:00:00 UTC 2026   (in UTC, with TZ=UTC)

# macOS / BSD date
date -r 1719360000

# Current Unix timestamp
date +%s

UTC vs. Local Time: The Part Everyone Gets Wrong

A Unix timestamp has no time zone. The number 1719360000 is the same instant whether you’re in Tokyo, London, or San Francisco. The time zone only enters the picture when you convert that instant into a human-readable date.

That means the same timestamp produces different wall-clock strings depending on where it’s rendered:

Practical rules to keep yourself sane:

• Store and transmit in UTC (or raw epoch). Never store a local-time string in a database.
• Convert to local time only at the last moment — in the UI, for display.
• Be explicit about the zone in every conversion. Functions that silently use “the server’s local time zone” cause bugs that only appear after you deploy to a server in a different region.
• Watch out for daylight saving time. Adding 86400 seconds is not always “the next day at the same wall-clock time,” because DST transitions shift the clock by an hour.

ISO 8601: The Format You Should Prefer

When you need a human-readable string that is also machine-parseable and unambiguous, use ISO 8601:

2026-06-26T00:00:00Z
2026-06-26T00:00:00+00:00
2026-06-25T17:00:00-07:00

The format is YYYY-MM-DDTHH:MM:SS followed by a time-zone designator — Z for UTC (the “Zulu” suffix) or an explicit offset like -07:00. ISO 8601 sorts correctly as plain text, is supported by virtually every language’s date parser, and removes the day/month ordering ambiguity that plagues formats like 06/07/2026. When in doubt, log and serialize dates as ISO 8601.

The Year 2038 Problem

If a system stores Unix time in a signed 32-bit integer, the largest value it can hold is 2147483647. That corresponds to 03:14:07 UTC on 19 January 2038. One second later, the integer overflows and wraps around to a large negative number — interpreted as 13 December 1901.

This is the “Year 2038 problem” (Y2038), the spiritual successor to Y2K. It affects older C programs, legacy embedded systems, and any code that explicitly uses a 32-bit time_t.

The fix is straightforward and already widespread: store timestamps in 64-bit integers. A 64-bit signed value pushes the overflow roughly 292 billion years into the future, which is comfortably beyond anything you need to schedule. Modern languages (JavaScript numbers, Python int, Go int64) and databases already use 64-bit time internally, so most new code is unaffected. The risk lives in legacy systems, fixed-width binary file formats, and hardware that’s hard to patch.

A related, much milder limit: JavaScript’s Date can only represent dates within ±100,000,000 days of the epoch (about ±273,000 years), and timestamps beyond Number.MAX_SAFE_INTEGER lose precision — but you’ll never hit that with real-world dates.

Common Mistakes and Pitfalls

• Mixing seconds and milliseconds. The number-one bug. Always confirm the unit. 10 digits ≈ seconds, 13 digits ≈ milliseconds for current dates.
• Forgetting the * 1000 in JavaScript. new Date(1719360000) gives you 20 January 1970, not 2026.
• Assuming local time when you meant UTC. Specify the time zone in every conversion; don’t rely on server defaults.
• Using deprecated naive functions like Python’s datetime.utcfromtimestamp(), which returns a time zone-unaware object.
• Storing formatted date strings instead of timestamps. Strings lose the unambiguous-instant property and invite parsing bugs.
• Ignoring leap seconds. Unix time deliberately ignores leap seconds, so it is not a perfect count of elapsed SI seconds — fine for almost everything, but worth knowing for high-precision timing.
• Negative timestamps. Dates before 1970 are valid and represented as negative numbers (e.g. -1 is 31 December 1969, 23:59:59 UTC). Some naive parsers choke on these.

Quick Reference

Convert a Timestamp Right Now

When you just need the answer without opening an editor, the free Timestamp Converter does it instantly: paste the number, read the UTC and local dates plus the ISO 8601 string, and copy the result. It runs entirely in your browser, so nothing you paste leaves your machine — handy for production log lines and tokens.

While you’re working with developer data, you might also find these guides useful: how to format JSON online for cleaning up API responses, and how to convert CSV to JSON for reshaping exported data.

Frequently Asked Questions

What is the difference between Unix seconds and milliseconds?

A Unix timestamp in seconds counts seconds since 1970-01-01 UTC, while a millisecond timestamp counts thousandths of a second. JavaScript uses milliseconds; most APIs and databases use seconds. As a quick check, a 10-digit number is seconds and a 13-digit number is milliseconds for any current date.

How do I convert a Unix timestamp to a human-readable date?

Paste the number into a timestamp converter, or in code call a date function: new Date(ts * 1000) in JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) in Python, or to_timestamp(ts) in PostgreSQL. Always confirm whether the input is in seconds or milliseconds before converting.

What is the Year 2038 problem?

Systems that store Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038 and wrap around to 1901. The fix is to store timestamps in 64-bit integers, which most modern languages and databases already do, so new code is generally safe.