You've probably seen something like this in a database column or API response:

"created_at": 1700000000

That's a Unix timestamp — a simple, timezone-independent way to represent a moment in time as a single integer. 1700000000 translates to November 14, 2023 at 22:13:20 UTC.

This guide explains what Unix timestamps are, why developers prefer them over date strings, and how to convert them in JavaScript, Python, and PHP.

What is a Unix Timestamp?

A Unix timestamp (also called epoch time) is the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC — a reference point known as the Unix epoch. The date is a historical artifact from the early days of Unix operating system development, but it's become a universal standard.

  • 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 key insight: a Unix timestamp is always UTC. It represents an absolute point in time with no timezone ambiguity.

Seconds vs. Milliseconds — and the Year 2038 Problem

Seconds vs. milliseconds

There are two common variants of Unix timestamp. The digit count is the easiest way to tell them apart:

UnitTypical digit countExample
Seconds (Unix time)10 digits1700000000
Milliseconds (Epoch ms)13 digits1700000000000

JavaScript's Date.now() returns milliseconds. Python's time.time() returns seconds (as a float). Know which your system expects before passing timestamps between services — feeding milliseconds to a function expecting seconds will produce dates in the year 2023... year 57000.

The Year 2038 Problem

Systems that store Unix timestamps as a 32-bit signed integer will overflow on January 19, 2038 at 03:14:07 UTC. After that point, the value wraps to a large negative number — representing a date in 1901.

Most modern systems use 64-bit integers, which can represent dates hundreds of billions of years into the future. But MySQL's TIMESTAMP column type and some legacy C code still use 32-bit — worth checking if you work with older systems.

Converting Timestamps in Code

Get the current timestamp

// JavaScript (milliseconds → divide by 1000 for seconds)
Date.now()                          // 1700000000000
Math.floor(Date.now() / 1000)       // 1700000000

# Python (seconds, as float)
import time
int(time.time())                    # 1700000000

# PHP (seconds)
time();                             # 1700000000

Timestamp → human-readable date

// JavaScript
new Date(1700000000 * 1000).toISOString()
// "2023-11-14T22:13:20.000Z"

new Date(1700000000 * 1000).toLocaleString('en-US', { timeZone: 'America/New_York' })
// "11/14/2023, 5:13:20 PM"

# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
# "2023-11-14T22:13:20+00:00"

# PHP
date('Y-m-d H:i:s', 1700000000);   // "2023-11-14 22:13:20"

Date string → timestamp

// JavaScript
new Date('2023-11-14T22:13:20Z').getTime() / 1000
// 1700000000

# Python
from datetime import datetime, timezone
datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc).timestamp()
# 1700000000.0

Calculate the difference between two timestamps

const start = 1700000000;
const end   = 1700086400;
const seconds = end - start;        // 86400
const days    = seconds / 86400;    // 1.0 day

Frequently Asked Questions

How do I tell if a timestamp is in seconds or milliseconds?
Count the digits. As of 2024, a seconds-based timestamp is 10 digits (around 1,700,000,000), while a milliseconds-based timestamp is 13 digits (around 1,700,000,000,000). If you receive an unknown timestamp, check whether dividing by 1000 gives a reasonable year. An easy sanity check: new Date(ts) in JavaScript — if it shows a date 50 years in the future, your timestamp is already in milliseconds.
What about timezones? Does a timestamp change based on location?
No — a Unix timestamp is always UTC-based and timezone-independent. The same moment in time produces the same timestamp everywhere on Earth. Timezones only come into play when you display the timestamp as a human-readable date. Best practice: store timestamps as UTC integers in your database, and apply timezone conversion only at the presentation layer.
Should I worry about the Year 2038 problem in new code?
For new code, no — use 64-bit integers or your language's built-in date types and you're fine. The concern is with legacy systems: MySQL's TIMESTAMP column type is affected (use DATETIME or BIGINT instead), as are some older C/C++ systems where time_t is 32-bit. If you're maintaining old infrastructure, it's worth auditing your timestamp storage types.

Key Takeaways

  • A Unix timestamp is the number of seconds since January 1, 1970 UTC — always timezone-neutral
  • 10-digit = seconds; 13-digit = milliseconds. Know which your system uses.
  • Timestamps are the most reliable way to store and compare dates across systems and languages
  • The Year 2038 problem only affects 32-bit integer storage — 64-bit is immune

Need to convert timestamps right now? These tools do it instantly in your browser.