Convert Unix Timestamp to Date: Complete Guide with Examples

The Problem: What Is That Number?

You are reading log files, debugging an API response, or looking at a database field, and you see a large integer where you expected a date. Something like 1711497600 or 1740009600. This is a Unix timestamp - also called epoch time or POSIX time - and once you understand the format, converting it to a human-readable date takes a single line of code in any language.

The short answer for this guide's example: 1711497600 is March 27, 2024 at 00:00:00 UTC. Read on to understand why, and how to do this conversion yourself in JavaScript, Python, PHP, Bash, and SQL.

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds that have elapsed since the Unix Epoch: midnight on January 1, 1970, Coordinated Universal Time (UTC). It is a single integer - always in UTC - with no timezone ambiguity. That is exactly why it became the universal standard for storing and exchanging time across systems.

The Unix timestamp at the moment this article was published (March 26, 2026 at 00:00:00 UTC) is 1742947200. By the time you read this, a few more seconds, minutes, or hours will have been added to that number.

Unix timestamps are always in UTC. They have no timezone. The conversion to a local date and time (e.g., "9:00 AM New York") happens at display time, in the client or application layer.

Why January 1, 1970? The Origin of the Epoch

The choice of January 1, 1970 as the epoch was largely practical. Unix was developed at Bell Labs in the late 1960s. When the developers needed a reference point for their time system, they picked a recent date that fit comfortably in the 32-bit integer space they were working with. 1970 was close enough to "now" in 1969 that the numbers would be manageable for years to come.

There was no deeper significance - no astronomical event, no historical milestone. It was simply a convenient anchor point. Other systems use different epochs: Microsoft's FILETIME starts at January 1, 1601. GPS time started January 6, 1980. Apple's Core Data uses January 1, 2001. Unix epoch won because Unix won.

Seconds vs. Milliseconds: The Most Common Trap

This is the single most common source of confusion with Unix timestamps. Different systems use different precisions:

• Unix / POSIX standard: seconds since epoch. Example: 1742947200 (10 digits for current dates)
• JavaScript Date.now(): milliseconds since epoch. Example: 1742947200000 (13 digits for current dates)
• Some high-precision APIs: microseconds (1742947200000000) or nanoseconds (1742947200000000000)

The quick rule: if your timestamp is 10 digits, it is probably seconds. If it is 13 digits, it is probably milliseconds. You can verify by checking whether the result is a plausible date - if converting a 13-digit number as seconds gives you the year 57,000 CE, you need to divide by 1000 first.

Converting milliseconds to seconds in any language: divide by 1000 (integer division).

How to Convert Unix Timestamp to Date: Code Examples

Here is the conversion in every major language, using the same example timestamp: 1742947200 (March 26, 2026 00:00:00 UTC).

JavaScript

// JavaScript Date() takes milliseconds, so multiply seconds by 1000
const timestamp = 1742947200;
const date = new Date(timestamp * 1000);

console.log(date.toISOString());
// "2026-03-26T00:00:00.000Z"

console.log(date.toLocaleString('en-US', { timeZone: 'America/New_York' }));
// "3/25/2026, 8:00:00 PM" (ET is UTC-4 in March)

// Get individual components
console.log(date.getUTCFullYear());  // 2026
console.log(date.getUTCMonth() + 1); // 3 (months are 0-indexed)
console.log(date.getUTCDate());      // 26

Note the critical detail: JavaScript's Date() constructor always expects milliseconds. Passing a seconds-based timestamp directly will give you a date in 1970 - a mistake every JavaScript developer makes at least once.

Python

import datetime

timestamp = 1742947200

# Convert to UTC datetime
dt_utc = datetime.datetime.utcfromtimestamp(timestamp)
print(dt_utc)
# 2026-03-26 00:00:00

# Convert to timezone-aware datetime (recommended)
dt_aware = datetime.datetime.fromtimestamp(timestamp, tz=datetime.timezone.utc)
print(dt_aware.isoformat())
# 2026-03-26T00:00:00+00:00

# Convert to a specific timezone
import zoneinfo
tz_ny = zoneinfo.ZoneInfo("America/New_York")
dt_ny = dt_aware.astimezone(tz_ny)
print(dt_ny.strftime("%Y-%m-%d %H:%M:%S %Z"))
# 2026-03-25 20:00:00 EDT

Use datetime.fromtimestamp(ts, tz=timezone.utc) rather than the older utcfromtimestamp() - the latter returns a naive datetime with no timezone info, which can cause silent bugs when you later compare datetimes or serialize them.

PHP

<?php
$timestamp = 1742947200;

// Basic conversion
echo date('Y-m-d H:i:s', $timestamp);
// 2026-03-26 00:00:00 (uses server's default timezone)

// Always specify timezone explicitly
$dt = new DateTime('@' . $timestamp); // @ prefix = Unix timestamp
$dt->setTimezone(new DateTimeZone('UTC'));
echo $dt->format('Y-m-d H:i:s T');
// 2026-03-26 00:00:00 UTC

// New York timezone
$dt->setTimezone(new DateTimeZone('America/New_York'));
echo $dt->format('Y-m-d H:i:s T');
// 2026-03-25 20:00:00 EDT
?>

The @ prefix in new DateTime('@' . $timestamp) is important - it tells PHP the input is a Unix timestamp and bypasses the server's default timezone, giving you a clean UTC starting point.

Bash / Linux Command Line

# GNU date (Linux)
date -d @1742947200
# Thu Mar 26 00:00:00 UTC 2026

# Format the output
date -d @1742947200 '+%Y-%m-%d %H:%M:%S %Z'
# 2026-03-26 00:00:00 UTC

# macOS uses BSD date - different syntax
date -r 1742947200
# Thu Mar 26 00:00:00 UTC 2026

# Get current Unix timestamp
date +%s
# 1742947200 (approximately)

The -d @ syntax is GNU date (Linux). On macOS, use -r instead. This distinction trips up developers who write scripts on Mac but run them on Linux servers.

SQL (PostgreSQL, MySQL, SQLite)

-- PostgreSQL: use to_timestamp()
SELECT to_timestamp(1742947200);
-- 2026-03-26 00:00:00+00

SELECT to_timestamp(1742947200) AT TIME ZONE 'America/New_York';
-- 2026-03-25 20:00:00

-- MySQL: use FROM_UNIXTIME()
SELECT FROM_UNIXTIME(1742947200);
-- 2026-03-26 00:00:00

SELECT FROM_UNIXTIME(1742947200, '%Y-%m-%d %H:%i:%s');
-- 2026-03-26 00:00:00

-- SQLite: use datetime() with 'unixepoch' modifier
SELECT datetime(1742947200, 'unixepoch');
-- 2026-03-26 00:00:00

-- Get current timestamp in all three
SELECT EXTRACT(EPOCH FROM NOW())::INT;   -- PostgreSQL
SELECT UNIX_TIMESTAMP();                  -- MySQL
SELECT strftime('%s', 'now');             -- SQLite

Go

package main

import (
    "fmt"
    "time"
)

func main() {
    timestamp := int64(1742947200)
    t := time.Unix(timestamp, 0).UTC()
    fmt.Println(t.Format(time.RFC3339))
    // 2026-03-26T00:00:00Z

    fmt.Println(t.Format("2006-01-02 15:04:05"))
    // 2026-03-26 00:00:00
}

Go's reference time is the unusual Mon Jan 2 15:04:05 MST 2006 - you use those exact values as a template for formatting. It is strange at first but becomes intuitive quickly.

Converting a Date Back to a Unix Timestamp (Reverse Conversion)

Equally important is the reverse: given a human-readable date, what is the Unix timestamp?

JavaScript (reverse)

// Date.UTC() takes year, month (0-indexed), day, hour, min, sec
const timestamp = Date.UTC(2026, 2, 26, 0, 0, 0) / 1000;
// Note: month 2 = March (0-indexed)
console.log(timestamp); // 1742947200

// From a date string
const ts2 = Math.floor(new Date('2026-03-26T00:00:00Z').getTime() / 1000);
console.log(ts2); // 1742947200

Python (reverse)

import datetime

dt = datetime.datetime(2026, 3, 26, 0, 0, 0, tzinfo=datetime.timezone.utc)
timestamp = int(dt.timestamp())
print(timestamp)  # 1742947200

Bash (reverse)

# GNU date
date -d "2026-03-26 00:00:00 UTC" +%s
# 1742947200

# macOS
date -j -f "%Y-%m-%d %H:%M:%S" "2026-03-26 00:00:00" +%s

Handling Timezones Correctly

Timezone bugs are the leading cause of off-by-one-hour (or multi-hour) errors in date calculations. The key rule: store timestamps in UTC, convert to local time only for display.

Here is how a timezone-safe workflow looks:

1. When a user submits a datetime, capture it with timezone information (e.g., the browser's Intl.DateTimeFormat().resolvedOptions().timeZone).
2. Convert to UTC before storing in your database.
3. Store as a Unix timestamp (integer) or an ISO 8601 UTC string.
4. When displaying to the user, convert from UTC to their local timezone using their stored timezone preference or browser's timezone.

Never store local time without its timezone offset. A value of 2026-03-26 08:00:00 with no timezone is ambiguous - it could mean 8 AM in New York, London, Tokyo, or anywhere else. You cannot reliably convert it to UTC later.

Reference: Notable Unix Timestamps

These are useful reference points for sanity-checking timestamps and understanding the range of the format:

• 0 - January 1, 1970 00:00:00 UTC (the Unix Epoch)
• 86400 - January 2, 1970 (one day = 86,400 seconds)
• 946684800 - January 1, 2000 00:00:00 UTC (Y2K)
• 1000000000 - September 9, 2001 01:46:40 UTC (Unix billennium)
• 1234567890 - February 13, 2009 23:31:30 UTC (famous milestone)
• 1742947200 - March 26, 2026 00:00:00 UTC (this article's publish date)
• 2147483647 - January 19, 2038 03:14:07 UTC (the Y2K38 problem - see below)
• 4102444800 - January 1, 2100 00:00:00 UTC

The Y2038 Problem

The Y2K38 problem (also called the Unix Millennium Bug or Y2038) is the timestamp equivalent of the Y2K bug. On January 19, 2038 at 03:14:07 UTC, a signed 32-bit integer timestamp will overflow from its maximum value (2,147,483,647) and wrap around to a large negative number, representing December 13, 1901.

Systems still using 32-bit signed integers to store timestamps - embedded systems, older databases, legacy C code - will malfunction at that moment. The fix is to migrate to 64 bit integers, which can store timestamps well past the year 292 billion.

Modern systems are generally safe: 64 bit Linux, modern databases, and most languages already use 64 bit timestamps. But if you are writing code for embedded systems or maintaining legacy C codebases, this is worth auditing now rather than scrambling in 2038.

Millisecond Timestamps: The JavaScript Legacy

JavaScript was designed in 1995, when the Unix timestamp convention was already well-established. Brendan Eich chose to use milliseconds instead of seconds for Date objects, likely for sub-second precision. This decision propagated to every JavaScript environment and many JSON APIs that were designed with JavaScript consumers in mind.

As a result, many modern web APIs return 13-digit millisecond timestamps. When you see a timestamp and are unsure of the unit, apply this quick check:

• 10 digits: likely seconds (covers years 2001–2286)
• 13 digits: likely milliseconds (covers the same range with ms precision)
• 16 digits: likely microseconds
• 19 digits: likely nanoseconds

You can also do a rough sanity check: the current Unix timestamp in seconds is approximately 1.74 billion. If your number is 1000x that (1.74 trillion), it is in milliseconds.

Frequently Asked Questions

What is the Unix timestamp right now?

The Unix timestamp changes every second, so the best way to get the current value is to use our Timestamp Converter, which shows the live current timestamp. As a reference: on March 26, 2026 at 00:00:00 UTC, the timestamp was 1742947200. Add 86,400 for each additional day. Or run date +%s in any Linux/macOS terminal.

Why does my converted date show the wrong time?

Almost always a timezone issue. Unix timestamps are in UTC. If your conversion function uses the local timezone of the machine or server running the code, the output will be offset from UTC by that timezone's offset. Always specify UTC explicitly unless you intentionally want local time. In JavaScript, use toISOString() for UTC or toLocaleString() with an explicit timeZone option.

Why is my JavaScript date off by one day?

This is almost always caused by passing a seconds-based timestamp to new Date() without multiplying by 1000. JavaScript's Date() expects milliseconds. A seconds-based timestamp like 1742947200 passed directly will be interpreted as 1,742,947,200 milliseconds - which is only 20 days after the Unix epoch (January 1970), not March 2026. Always do new Date(timestamp * 1000) when your timestamp is in seconds.

What is the maximum Unix timestamp a 32-bit system can handle?

A signed 32-bit integer can hold a maximum value of 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC. This is the Y2038 problem. Systems using 64 bit integers can store timestamps until the year 292,277,026,596 - effectively forever for practical purposes.

How do I convert a date string like "2026-03-26" to a Unix timestamp?

The safest approach in any language is to parse the date string with explicit timezone handling and then convert to a timestamp. In JavaScript: Math.floor(new Date('2026-03-26T00:00:00Z').getTime() / 1000). In Python: int(datetime.datetime(2026, 3, 26, tzinfo=datetime.timezone.utc).timestamp()). Always append Z or specify UTC when parsing ISO date strings to avoid the string being interpreted in local time.

What is the difference between Unix time, epoch time, and POSIX time?

They all refer to the same thing: seconds elapsed since January 1, 1970 00:00:00 UTC, ignoring leap seconds. "Unix time" and "epoch time" are informal names for the same concept. "POSIX time" is the formal name as defined in the POSIX standard. You will see all three terms used interchangeably in documentation, and they can be treated as synonyms.

Related reading: Timestamp Converter Tool · Cron Expression Parser · JSON Formatting Best Practices