Unix Timestamps Explained — Working with Dates in Web Development

At some point, every developer encounters a number like 1741046400 and wonders what it means. That's a Unix timestamp — the number of seconds elapsed since January 1, 1970, 00:00:00 UTC (the "Unix epoch"). It's how most systems store and exchange dates internally.

Use Intoolhub's Timestamp Converter to convert timestamps instantly while reading this guide.

What Is the Unix Epoch?

The Unix epoch — midnight on January 1, 1970, Coordinated Universal Time — was chosen as the reference point when Unix was designed in the late 1960s. Every Unix timestamp counts seconds from that moment.

Seconds vs. Milliseconds

This is the most common source of timestamp bugs. JavaScript uses milliseconds; Unix/Linux commands and most databases use seconds.

Date.now() // 1741046400000 — milliseconds (JavaScript)
Math.floor(Date.now() / 1000) // 1741046400 — seconds (Unix)

When you receive a timestamp, check the magnitude. A 13-digit number is milliseconds; a 10-digit number is seconds. The Timestamp Converter handles both automatically.

Converting Timestamps in Code

JavaScript / TypeScript

// Current timestamp
const nowSeconds = Math.floor(Date.now() / 1000)
const nowMs = Date.now()

// Timestamp to Date object
const date = new Date(1741046400 * 1000) // multiply by 1000 for ms
console.log(date.toISOString()) // "2025-03-01T08:00:00.000Z"

// Date to timestamp
const ts = Math.floor(new Date('2025-03-01').getTime() / 1000)

Python

import time
from datetime import datetime, timezone

# Current timestamp
now = int(time.time())

# Timestamp to datetime
dt = datetime.fromtimestamp(1741046400, tz=timezone.utc)
print(dt.isoformat())  # 2025-03-01T08:00:00+00:00

# datetime to timestamp
ts = int(datetime(2025, 3, 1, tzinfo=timezone.utc).timestamp())

SQL

-- Current timestamp
SELECT UNIX_TIMESTAMP();              -- MySQL
SELECT EXTRACT(EPOCH FROM NOW());     -- PostgreSQL

-- Convert to readable
SELECT FROM_UNIXTIME(1741046400);     -- MySQL
SELECT TO_TIMESTAMP(1741046400);      -- PostgreSQL

Time Zone Pitfalls

Time zones are the single greatest source of date/time bugs. A few rules to live by:

Store everything in UTC

Never store local time in a database. Always store UTC and convert to the user's local time at display.

Use ISO 8601 for string representation

2025-03-01T08:00:00Z       ← Z means UTC
2025-03-01T10:00:00+02:00  ← with offset

ISO 8601 strings sort lexicographically, making them safe to sort as strings.

Never assume UTC in JavaScript's new Date()

new Date('2025-03-01') // UTC midnight (safe — date-only string)
new Date('2025-03-01 08:00:00') // Local time! (unsafe — ambiguous)
new Date('2025-03-01T08:00:00Z') // UTC explicitly (safe)

Daylight Saving Time

DST means clocks jump forward or back, creating gaps and overlaps. If you're scheduling events across DST transitions, use a proper date-time library:

• JavaScript: date-fns, Temporal API (upcoming)
• Python: pendulum

The Year 2038 Problem

32-bit systems store Unix timestamps as a signed 32-bit integer. The maximum value, 2147483647, corresponds to January 19, 2038. After that, a signed 32-bit integer overflows to a large negative number.

Most modern systems use 64-bit timestamps, which won't overflow until the year 292,277,026,596. Ensure any legacy embedded systems or databases in your infrastructure have been migrated.

Quick Reference

→ Open Timestamp Converter