Unix Timestamp Explained: Complete Guide to Epoch Time

A comprehensive guide to Unix timestamps covering what they are, how they work, conversion methods, and common use cases in software development.

Why January 1, 1970?

The Unix operating system was developed in the late 1960s, and its creators needed a reference point for time. They chose midnight on January 1, 1970 UTC as the starting point. This date was close enough to be useful but far enough back to not require negative numbers for most practical purposes.

Examples

Simple Math

Unix timestamps are just integers representing elapsed seconds:

Current time: 1699999999
One hour later: 1699999999 + 3600 = 1700003599
One day later: 1699999999 + 86400 = 1700086399

Seconds in a minute: 60
Seconds in an hour: 3600
Seconds in a day: 86400
Seconds in a year: ~31536000 (non-leap)

Time Zones

Unix timestamps are always in UTC. The same timestamp represents the same instant everywhere in the world. Time zone conversion happens when displaying to users:

Timestamp: 1699999999

In UTC:     Nov 14, 2023 22:13:19
In New York: Nov 14, 2023 17:13:19 (UTC-5)
In Tokyo:   Nov 15, 2023 07:13:19 (UTC+9)
// Same moment in time, different local representations

Advantages of Unix Time

• Universal: Works the same everywhere, no timezone confusion
• Sortable: Later times have larger numbers
• Math-friendly: Easy to calculate durations
• Compact: Single integer vs. date string
• Unambiguous: No format parsing issues

Watch out for the difference between seconds and milliseconds:

Converting Between Them

// Seconds to milliseconds
seconds = 1699999999
milliseconds = seconds * 1000  // 1699999999000

// Milliseconds to seconds
milliseconds = 1699999999000
seconds = Math.floor(milliseconds / 1000)  // 1699999999

Auto-Detection

Our Unix Timestamp Converter can auto-detect whether you've entered seconds or milliseconds based on the number of digits.

JavaScript

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

// Current timestamp (seconds)
Math.floor(Date.now() / 1000)  // 1699999999
// Timestamp to Date
new Date(1699999999 * 1000)  // If seconds
new Date(1699999999000)       // If milliseconds
// Date to timestamp
const date = new Date('2023-11-14T22:13:19Z');
date.getTime()      // 1699999999000 (milliseconds)
date.getTime() / 1000  // 1699999999 (seconds)

Python

import time
from datetime import datetime

# Current timestamp
time.time()  # 1699999999.123456
# Timestamp to datetime
datetime.fromtimestamp(1699999999)       # Local time
datetime.utcfromtimestamp(1699999999)    # UTC
# Datetime to timestamp
dt = datetime(2023, 11, 14, 22, 13, 19)
dt.timestamp()  # 1699999999.0

PHP

// Current timestamp
time();  // 1699999999

// Timestamp to date string
date('Y-m-d H:i:s', 1699999999);  // "2023-11-14 22:13:19"
// Date string to timestamp
strtotime('2023-11-14 22:13:19');  // 1699999999

SQL

-- MySQL
SELECT UNIX_TIMESTAMP();  -- Current timestamp
SELECT FROM_UNIXTIME(1699999999);  -- To datetime
SELECT UNIX_TIMESTAMP('2023-11-14 22:13:19');  -- From datetime

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW());  -- Current timestamp
SELECT TO_TIMESTAMP(1699999999);  -- To datetime

Command Line

# Linux/macOS
date +%s  # Current timestamp
date -d @1699999999  # Timestamp to date

# Windows PowerShell
[int][double]::Parse((Get-Date -UFormat %s))  # Current
[DateTimeOffset]::FromUnixTimeSeconds(1699999999)

1. API Responses

{
"created_at": 1699999999,
"updated_at": 1700086399,
"expires_at": 1702591999
}

Timestamps are ideal for APIs because they're language-agnostic and unambiguous.

2. Database Storage

Many databases store dates as timestamps internally:

CREATE TABLE events (
id INT PRIMARY KEY,
name VARCHAR(255),
event_date INT  -- Unix timestamp
);

-- Query: events in the last 7 days
SELECT * FROM events
WHERE event_date > UNIX_TIMESTAMP() - 604800;

3. Caching & Expiration

const cacheEntry = {
data: {...},
expires: Date.now() + 3600000  // 1 hour from now
};

function isExpired(entry) {
return Date.now() > entry.expires;
}

4. Log Files

1699999999 INFO User logged in
1700000123 WARN Rate limit approaching
1700000456 ERROR Database connection failed

Timestamps make logs sortable and easy to filter by time range.

5. JWT Tokens

{
"sub": "user123",
"iat": 1699999999,  // Issued at
"exp": 1700086399,  // Expires at
"nbf": 1699999999   // Not valid before
}

6. Rate Limiting

// Sliding window rate limiter
const requests = [];
const windowMs = 60000; // 1 minute
const maxRequests = 100;

function isAllowed() {
const now = Date.now();
// Remove requests outside window
while (requests.length && requests[0] < now - windowMs) {
requests.shift();
}
if (requests.length < maxRequests) {
requests.push(now);
return true;
}
return false;
}

The Year 2038 Problem

32-bit systems store timestamps as signed 32-bit integers, which will overflow on January 19, 2038 at 03:14:07 UTC.

Max 32-bit signed: 2,147,483,647
That timestamp:    Jan 19, 2038 03:14:07 UTC

// One second later wraps to negative number
// System thinks it's Dec 13, 1901

Solution: Use 64-bit timestamps. Most modern systems already do this.

Timezone Confusion

// Wrong: assuming local time
new Date(1699999999 * 1000).toString()
// "Tue Nov 14 2023 17:13:19 GMT-0500" (varies by system)

// Right: explicitly use UTC
new Date(1699999999 * 1000).toUTCString()
// "Tue, 14 Nov 2023 22:13:19 GMT" (same everywhere)

Leap Seconds

Unix time ignores leap seconds. Each day is exactly 86,400 seconds, even during leap second insertions. This means Unix time isn't perfectly synchronized with astronomical time, but the difference is negligible for most applications.

Negative Timestamps

Dates before 1970 have negative timestamps:

Moon landing: -14182940  // July 20, 1969
WW2 end:      -770000000 // August 15, 1945

// Some systems don't handle negatives well
// Test with historical dates if needed