Unix Timestamp Conversion — The Developer’s Quick Reference Guide

It is 3 AM and your production logs show an error at timestamp 1740268800. Your brain is not converting that to February 23, 2025 at midnight UTC on its own. You need a converter, and you need it fast. This guide is the reference you bookmark and come back to every time timestamps make your head spin.

Unix timestamps — the number of seconds since January 1, 1970 (the Unix epoch) — are the lingua franca of time in computing. Databases store them, APIs return them, log files are full of them. They are unambiguous, timezone-neutral, and easy to sort. They are also completely unreadable to humans. Here is everything you need to work with them efficiently.

Landmark Timestamps Worth Memorizing

Having a few reference points in your head makes it easier to sanity-check values you encounter in the wild:

• 0 — January 1, 1970 00:00:00 UTC (the epoch)
• 1000000000 — September 9, 2001 (the first 10-digit timestamp)
• 1234567890 — February 13, 2009 23:31:30 UTC
• 1700000000 — November 14, 2023
• 1750000000 — June 15, 2025
• 1800000000 — January 15, 2027
• 2000000000 — May 18, 2033
• 2147483647 — January 19, 2038 (the Y2K38 problem for 32-bit systems)

If a timestamp starts with 17, it is from 2023–2027. If it starts with 16, it is from 2020–2023. This rough mental math helps you spot obviously wrong values immediately.

Seconds vs Milliseconds: The Most Common Bug

The single most frequent timestamp bug is mixing up seconds and milliseconds. A Unix timestamp in seconds has 10 digits in the current era (like 1740268800). A millisecond timestamp has 13 digits (like 1740268800000). Pass a millisecond value to a function expecting seconds, and you get a date in the year 57000.

How Different Systems Handle It

• JavaScript — Date.now() returns milliseconds. new Date() expects milliseconds.
• Python — time.time() returns seconds as a float. datetime.fromtimestamp() expects seconds.
• Java — System.currentTimeMillis() returns milliseconds. Instant.ofEpochSecond() expects seconds.
• Go — time.Now().Unix() returns seconds. time.Now().UnixMilli() returns milliseconds.
• PostgreSQL — EXTRACT(EPOCH FROM now()) returns seconds as a decimal.
• MySQL — UNIX_TIMESTAMP() returns seconds as an integer.

Conversion Snippets for Every Language

Bookmark these. You will use them more often than you think.

JavaScript

// Current timestamp (seconds)
Math.floor(Date.now() / 1000);

// Timestamp to date string
new Date(1740268800 * 1000).toISOString();
// "2025-02-23T00:00:00.000Z"

// Date string to timestamp
Math.floor(new Date("2025-02-23").getTime() / 1000);
// 1740268800

Python

from datetime import datetime, timezone

# Current timestamp
int(datetime.now(timezone.utc).timestamp())

# Timestamp to datetime
datetime.fromtimestamp(1740268800, tz=timezone.utc)
# datetime(2025, 2, 23, 0, 0, tzinfo=timezone.utc)

# Datetime to timestamp
int(datetime(2025, 2, 23, tzinfo=timezone.utc).timestamp())
# 1740268800

Go

// Current timestamp
time.Now().Unix()

// Timestamp to time.Time
t := time.Unix(1740268800, 0).UTC()

// time.Time to timestamp
t.Unix()

SQL (PostgreSQL)

-- Timestamp to date
SELECT to_timestamp(1740268800) AT TIME ZONE 'UTC';

-- Date to timestamp
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2025-02-23 00:00:00');

Timezone Pitfalls That Cause Production Bugs

Unix timestamps are always UTC. The bugs happen when you convert them to local time without being explicit about the timezone.

The Silent Offset

In JavaScript, new Date(1740268800000).toString() returns a string in the browser's local timezone. If your server is in UTC and your user is in EST, the same timestamp displays as two different dates near midnight. This is how "off by one day" bugs are born.

Always use .toISOString() or explicitly specify the timezone with Intl.DateTimeFormat. Never rely on the default .toString() for anything user-facing.

Daylight Saving Time Gaps

When clocks spring forward, there is a gap. 2:00 AM becomes 3:00 AM, and timestamps in that hour do not correspond to valid local times. When clocks fall back, there is an overlap — the same local time occurs twice. If you store local times instead of UTC timestamps, you will eventually hit both of these edge cases.

The rule is simple: store timestamps in UTC (or as Unix timestamps), convert to local time only for display.

The Y2K38 Problem: Should You Worry?

On January 19, 2038 at 03:14:07 UTC, 32-bit signed integers overflow. The timestamp 2147483647 wraps to -2147483648, which represents December 13, 1901. This is the Y2K38 problem.

Most modern systems use 64-bit timestamps, which will not overflow for another 292 billion years. But embedded systems, legacy databases, and some file formats still use 32-bit timestamps. If you are building something that needs to handle dates beyond 2038, verify your entire stack uses 64-bit time.

ISO 8601 vs Unix Timestamps: When to Use Which

Unix timestamps are ideal for storage, sorting, and computation. ISO 8601 strings like 2025-02-23T00:00:00Z are ideal for APIs, logs, and anything humans might read.

• Use Unix timestamps for database columns, cache expiration, JWT expiry (exp claim), and internal computations
• Use ISO 8601 for API responses, log messages, configuration files, and user-facing displays
• Use both when debugging — log the timestamp and the human-readable version side by side

For a deeper dive into timestamp formats and conversion workflows, check out our complete guide to AI timestamp conversion.

Related Tools and Resources

• AI Timestamp Converter — instant conversion with auto-format detection
• AI Timestamp Converter Guide — in-depth tutorial on timestamp conversion
• AI Crontab Generator — schedule tasks with human-readable cron expressions
• AI Countdown Timer — track deadlines and events
• AI JSON Formatter — format API responses that contain timestamps
• JSON Formatter Guide — debug API responses with nested timestamp fields