How to Convert a Unix Timestamp to a Date

A Unix timestamp looks like this: 1712505600.

It means nothing to a human at a glance. But it represents a specific moment in time — April 7, 2024 at 16:00:00 UTC, to be exact. Converting it to something readable is straightforward, but there are a handful of ways it goes wrong if you are not paying attention.

This guide covers how to convert a Unix timestamp to a human-readable date in the most common languages and environments, what the typical mistakes are, and how to handle seconds vs milliseconds — which is where most bugs come from.

If you just need a quick conversion right now, the Unix Timestamp Converter does it instantly.

What You Are Actually Converting

A Unix timestamp is the number of seconds (or sometimes milliseconds) since January 1, 1970, 00:00:00 UTC. That starting point is called the Unix epoch.

When you convert a timestamp to a date, you are answering: "what calendar date and time does this number of seconds correspond to, in a given timezone?"

The answer depends on two things: the timestamp value itself, and the timezone you want the output in. The same timestamp is a different local time depending on where you are. That is intentional — the timestamp stores a single universal moment, and you apply the timezone at display time.

Seconds vs Milliseconds: The Most Common Source of Bugs

Before converting anything, check whether your timestamp is in seconds or milliseconds.

Unix timestamps in seconds are 10 digits right now (around 1,700,000,000 as of late 2023). JavaScript's Date.now() returns milliseconds, giving you a 13-digit number like 1,700,000,000,000.

If you feed a millisecond timestamp into a function that expects seconds, you will get a date somewhere in the year 55,000. If you feed a second timestamp into a function that expects milliseconds, you will get a date in January 1970.

A fast check: count the digits. 10 digits = seconds. 13 digits = milliseconds.

How to Convert in JavaScript

JavaScript's Date object works in milliseconds, so if you have a seconds-based timestamp, multiply by 1000 first.

const ts = 1712505600; // seconds
const date = new Date(ts * 1000);

console.log(date.toISOString()); // "2024-04-07T16:00:00.000Z"
console.log(date.toLocaleString()); // local timezone string

If your timestamp is already in milliseconds:

const ts = 1712505600000; // milliseconds
const date = new Date(ts);

toISOString() always returns UTC. toLocaleString() uses the user's local timezone. If you need a specific timezone, use toLocaleString with an options object:

date.toLocaleString('en-GB', { timeZone: 'Europe/London' });

How to Convert in Python

Python's datetime module handles this cleanly.

from datetime import datetime, timezone

ts = 1712505600  # seconds
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt)  # 2024-04-07 16:00:00+00:00

fromtimestamp without a tz argument uses the local system timezone, which can cause inconsistent results depending on the machine. Pass tz=timezone.utc to be explicit, then convert to local time if needed:

from datetime import timezone
import pytz

local_tz = pytz.timezone('America/New_York')
local_dt = dt.astimezone(local_tz)
print(local_dt)  # 2024-04-07 12:00:00-04:00

For millisecond timestamps, divide by 1000 before passing to fromtimestamp.

How to Convert in PHP

$ts = 1712505600;
echo date('Y-m-d H:i:s', $ts); // "2024-04-07 16:00:00" in server timezone
echo gmdate('Y-m-d H:i:s', $ts); // always UTC

date() uses the server's default timezone. gmdate() always returns UTC. In most production PHP code, setting the timezone explicitly is safer than relying on the server default.

How to Convert in Go

import (
    "fmt"
    "time"
)

ts := int64(1712505600)
t := time.Unix(ts, 0).UTC()
fmt.Println(t.Format(time.RFC3339)) // "2024-04-07T16:00:00Z"

time.Unix(seconds, nanoseconds) takes the timestamp in seconds. Call .UTC() to normalize to UTC, or .Local() to apply the system timezone.

How to Convert in SQL

Timestamps stored as integers are common in databases, especially for created_at and updated_at columns.

PostgreSQL: `sql SELECT TO_TIMESTAMP(1712505600); -- 2024-04-07 16:00:00+00 `

MySQL: `sql SELECT FROM_UNIXTIME(1712505600); -- 2024-04-07 16:00:00 (server timezone) `

SQLite: `sql SELECT datetime(1712505600, 'unixepoch'); -- 2024-04-07 16:00:00 `

SQLite stores everything as text or numbers and has no native datetime type, so the unixepoch modifier tells it to treat the integer as a Unix timestamp.

Formatting the Output

Converting to a date object is the first step. Formatting it for display is the second.

Common format codes:

ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ) is the safest choice for anything that crosses system boundaries or gets stored in a database. It is unambiguous, sortable as a string, and universally understood.

Handling Timezone Correctly

The same timestamp represents different local times. 1712505600 is:

• 16:00 UTC
• 12:00 Eastern (UTC-4 during daylight saving)
• 18:00 Central European (UTC+2 during summer)

If you convert a UTC timestamp to a "local" time without specifying which timezone you mean, you will get whatever timezone the machine running the code is set to. That causes bugs when the same code runs on servers in different regions.

Best practice: store and transmit timestamps in UTC, convert to local time only at display time, and always be explicit about which timezone you are targeting.

When the Result Looks Wrong

A few quick diagnostics if the conversion gives an unexpected result:

• Year is 55,000+: timestamp is in milliseconds but the function expected seconds
• Date is 1970-01-01: timestamp is in seconds but the function expected milliseconds, or the timestamp is 0 or null
• Time is off by a few hours: timezone mismatch — check whether you are comparing UTC output to a local clock
• Negative timestamp: valid — negative timestamps represent dates before 1970, which most systems handle correctly

A Faster Way to Check

For quick spot checks — like verifying a timestamp from an API response or a log file — the Unix Timestamp Converter handles the conversion instantly, including detecting seconds vs milliseconds automatically.

It is useful when you are debugging and need to confirm what a timestamp actually represents without writing code. For working out date arithmetic like "how many days since this timestamp", the Days Between Dates calculator is the natural next step.