Unix Timestamps for Web Developers: A Complete Reference

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 — an arbitrary reference point called the Unix epoch. It is the universal representation of a point in time in computing: a single integer that is compact, timezone-agnostic, and trivially comparable, sortable, and arithmetically manipulable.

As of mid-2026, the Unix timestamp is approximately 1750000000. You will encounter Unix timestamps in API responses, database records, log files, JWT claims (iat, exp, nbf), HTTP headers (Last-Modified, Expires), SSL/TLS certificate validity fields, and cron scheduling systems.

// Current Unix timestamp in JavaScript
Math.floor(Date.now() / 1000)  // seconds
Date.now()                     // milliseconds (JavaScript-specific)

// Python
import time
int(time.time())  # seconds

// Go
import "time"
time.Now().Unix()  // seconds

The Critical Milliseconds vs. Seconds Trap

The most common source of timestamp bugs is a unit mismatch. The Unix standard uses seconds, but JavaScript's Date object uses milliseconds internally. This means:

• Date.now() → milliseconds (e.g., 1750000000000)
• Math.floor(Date.now() / 1000) → seconds (e.g., 1750000000)
• new Date(timestamp) → expects milliseconds; passing seconds gives a date in January 1970

// Bug: treating seconds as milliseconds
const ts = 1750000000; // Unix timestamp in seconds
new Date(ts);          // 1970-01-21T06:13:20.000Z — WRONG

// Fix: convert to milliseconds first
new Date(ts * 1000);   // 2025-06-15T... — correct

// Detecting the unit from the magnitude
const isMilliseconds = ts > 1e12; // true for ms, false for seconds

Database drivers for Node.js (PostgreSQL, MySQL, MongoDB) typically return timestamps as JavaScript Date objects or millisecond integers. Always check the documentation of each driver to understand what unit it uses.

Timezone Handling: The Second Major Pitfall

Unix timestamps are always UTC — they have no timezone embedded. The timezone question only arises when you display a timestamp to a human. This is where most timestamp bugs originate:

const ts = 1750000000;
const date = new Date(ts * 1000);

// UTC representation
date.toISOString();                         // "2025-06-15T..."

// Local timezone (varies by machine running the code)
date.toLocaleString();                      // depends on system timezone

// Specific timezone (preferred for production)
date.toLocaleString('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'full',
  timeStyle: 'long'
});

Recommended practice: Store timestamps as Unix integers in your database. Only convert to a human-readable representation at the display layer, using the user's timezone preference — not the server's local timezone. This prevents a class of bugs where dates appear wrong for users in different timezones.

Arithmetic with Timestamps

One of the key advantages of Unix timestamps is that date arithmetic becomes simple integer math:

const now = Math.floor(Date.now() / 1000);

const oneHourLater    = now + 3600;       // 60 * 60
const oneDayLater     = now + 86400;      // 60 * 60 * 24
const oneWeekLater    = now + 604800;     // 60 * 60 * 24 * 7
const thirtyDaysLater = now + 2592000;    // 60 * 60 * 24 * 30

// JWT expiration check
function isTokenExpired(exp) {
  return Math.floor(Date.now() / 1000) > exp;
}

Be careful with months and years — they have variable lengths (28–31 days, 365 or 366 days). For those intervals, use a date library like date-fns or Temporal (the modern JavaScript date API) rather than manual arithmetic.

ISO 8601 vs. Unix Timestamps

ISO 8601 strings (2025-06-15T14:30:00Z) are human-readable and self-describing. Unix timestamps are compact and fast for computation. The two formats serve different purposes:

A common convention is to store Unix timestamps in your database and convert to ISO 8601 when returning data from your API — giving API consumers a human-readable string while keeping storage efficient.

The Year 2038 Problem

32-bit signed integers can represent values up to 2,147,483,647 — which corresponds to January 19, 2038, at 03:14:07 UTC. Systems that store Unix timestamps as 32-bit integers will overflow at that point, wrapping to a large negative number. This is the Unix equivalent of Y2K.

Modern 64-bit systems are not affected — a 64-bit signed integer can represent timestamps for approximately 292 billion years. If you are writing code that might still be running in 2038 (embedded systems, old databases), ensure timestamps are stored as 64-bit integers (BIGINT in SQL, int64 in Go, long in Java).

Converting Timestamps in Different Languages

# Python — seconds to datetime
from datetime import datetime, timezone
dt = datetime.fromtimestamp(1750000000, tz=timezone.utc)
print(dt.isoformat())  # 2025-06-15T...+00:00

# Go — seconds to time.Time
import "time"
t := time.Unix(1750000000, 0).UTC()

# Ruby
Time.at(1750000000).utc

# PHP
date('Y-m-d H:i:s', 1750000000)

# SQL (PostgreSQL)
SELECT to_timestamp(1750000000);

# SQL (MySQL)
SELECT FROM_UNIXTIME(1750000000);

Use the Copynix Timestamp Converter

When working with timestamps during development — reading API responses, debugging JWT expiration, checking database records — use the Copynix Unix Timestamp Converter to convert any timestamp to a human-readable date instantly. It accepts both seconds and milliseconds automatically, shows UTC and local time simultaneously, and runs entirely in your browser without sending your data anywhere.

Summary

Unix timestamps are the backbone of time handling in server-side software. The key points: always use 64-bit integers for storage, be explicit about seconds vs. milliseconds (JavaScript's biggest timestamp footgun), store in UTC and convert to user timezone only at the display layer, and use a proper date library for month/year arithmetic rather than manual math.