Unix Timestamp: What It Is and How to Convert It

Every developer eventually runs into a number like 1700000000 in a database, API response, or log file and wonders: what date is that? The answer is a Unix timestamp — one of the most fundamental time representations in computing.

What Is a Unix Timestamp?

A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a moment known as the Unix Epoch.

For example:

• 0 = January 1, 1970 00:00:00 UTC
• 1000000000 = September 9, 2001 01:46:40 UTC
• 1700000000 = November 14, 2023 22:13:20 UTC
• 2000000000 = May 18, 2033 03:33:20 UTC

The beauty of Unix timestamps is their simplicity: a single integer represents an exact moment in time, with no timezone ambiguity, no date format variations, and easy arithmetic.

Seconds vs. Milliseconds: How to Tell the Difference

There are three common formats:

The quick rule: count the digits. For current dates (2020s), seconds timestamps have 10 digits, milliseconds have 13, and microseconds have 16. If you see a number around 1.7 billion, it’s seconds. If it’s around 1.7 trillion, it’s milliseconds.

Converting between them:

const seconds = 1700000000;
const milliseconds = seconds * 1000;       // 1700000000000
const microseconds = seconds * 1000000;    // 1700000000000000

// Back to seconds
const fromMs = Math.floor(milliseconds / 1000);
const fromUs = Math.floor(microseconds / 1000000);

JavaScript’s Date.now() returns milliseconds. Most Unix systems and databases use seconds. This is a constant source of bugs — if you pass seconds to a function expecting milliseconds, you get a date in January 1970. If you pass milliseconds where seconds are expected, you get a date millions of years in the future.

Converting in Different Languages

JavaScript:

// Current timestamp (milliseconds)
Date.now()                          // 1700000000000

// Timestamp to Date
new Date(1700000000 * 1000)         // if seconds
new Date(1700000000000)             // if milliseconds

// Date to timestamp (seconds)
Math.floor(Date.now() / 1000)

Python:

import time, datetime

# Current timestamp
time.time()                         # 1700000000.123

# Timestamp to datetime (local timezone)
datetime.datetime.fromtimestamp(1700000000)

# Timestamp to datetime (UTC) — the correct way since Python 3.12
datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc)
# Note: datetime.utcfromtimestamp() is deprecated since Python 3.12
# because it creates a naive datetime without timezone info

# Datetime to timestamp
datetime.datetime(2023, 11, 14, tzinfo=datetime.timezone.utc).timestamp()

SQL (PostgreSQL):

-- Timestamp to date
SELECT to_timestamp(1700000000);

-- Date to timestamp
SELECT EXTRACT(EPOCH FROM NOW());

Bash:

# Current timestamp
date +%s

# Timestamp to date
date -d @1700000000

# Date to timestamp
date -d "2023-11-14" +%s

The Year 2038 Problem

Unix timestamps are traditionally stored as signed 32-bit integers, which can represent values up to 2,147,483,647. That number corresponds to January 19, 2038, 03:14:07 UTC.

After that moment, a 32-bit timestamp overflows and wraps around to negative numbers — interpreting as December 1901. This is the “Y2K38” problem.

The fix: use 64-bit integers, which won’t overflow for approximately 292 billion years. Most modern operating systems, databases, and programming languages have already migrated to 64-bit timestamps. However, embedded systems, legacy code, and some file formats may still be vulnerable.

Timestamps and Timezones

Unix timestamps are always UTC. They represent an absolute moment in time regardless of timezone. This is one of their key advantages over formatted date strings.

When you convert a timestamp to a human-readable date, the result depends on the timezone of the system doing the conversion:

• 1700000000 in UTC = November 14, 2023 22:13:20
• 1700000000 in EST (UTC-5) = November 14, 2023 17:13:20
• 1700000000 in JST (UTC+9) = November 15, 2023 07:13:20

Same timestamp, different local times — but they all refer to the same instant.

Common Gotchas

Mixing seconds and milliseconds. If you pass a seconds timestamp to a function expecting milliseconds, you’ll get a date in January 1970. If you pass milliseconds where seconds are expected, you’ll get a date millions of years in the future.

Leap seconds. Unix time does not account for leap seconds. The UTC clock occasionally adds a second to stay synchronized with Earth’s rotation, but Unix timestamps skip these. In practice, this rarely matters.

Negative timestamps. Dates before January 1, 1970 are represented as negative numbers. −86400 is December 31, 1969. Most languages handle this correctly, but some older systems don’t.

Try It Yourself

Use our Unix Timestamp Converter to convert between timestamps and human-readable dates instantly — right in your browser.

If you work with scheduled tasks that use Unix time, our Cron Expression Parser helps build and validate cron schedules — see the cron syntax guide for a detailed walkthrough, or grab the Cron Cheat Sheet for a quick reference. For API debugging where timestamps appear in JSON payloads, the guide on how to read and debug JSON covers practical techniques.

Further Reading

• POSIX.1-2024: Seconds Since the Epoch — The authoritative definition of Unix time
• Wikipedia: Year 2038 Problem — Overview of the 32-bit timestamp overflow
• MDN: Date.now() — JavaScript millisecond timestamps
• Google Leap Smear — How Google handles leap seconds in timestamps
• UTC vs Unix Time — Deep dive on leap seconds and time standards