Unix Timestamps Explained: Converting Dates for Developers

What is a Unix Timestamp?

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a moment known as the Unix epoch. Right now, as you read this, the timestamp is a 10-digit number somewhere above 1,700,000,000.

This seemingly arbitrary counting system is the backbone of time representation in computing. Databases store timestamps, APIs return them, log files record them, and authentication tokens expire based on them.

The beauty of Unix timestamps is their simplicity. A timestamp is just a number. It has no time zone, no formatting, no ambiguity. 1704067200 means the same thing everywhere in the world: January 1, 2024, at midnight UTC. No confusion about date formats (is 01/02/2024 January 2nd or February 1st?), no daylight saving time complications.

Why Developers Use Timestamps

Unix timestamps solve several problems that human-readable dates create:

• Time zone independence: A timestamp is always UTC. You convert to local time at the display layer, never in storage or business logic. This eliminates an entire category of bugs.
• Easy math: Adding 3600 seconds means "one hour later." Subtracting two timestamps gives you the duration between events in seconds. No need for date parsing libraries just to calculate elapsed time.
• Sorting: Timestamps sort correctly as plain numbers. "2024-01-15" vs "2024-02-01" requires string comparison logic. 1705276800 vs 1706745600 is a simple numeric comparison.
• Compact storage: A 32-bit integer (4 bytes) stores any date from 1970 to 2038. A 64-bit integer covers billions of years. The equivalent ISO 8601 string "2024-01-15T10:30:00Z" takes 20 bytes.
• Cross-platform consistency: Every programming language, database, and operating system understands Unix timestamps. The same number means the same moment everywhere.

Convert between timestamps and human-readable dates instantly with our Unix Timestamp Converter.

Seconds vs Milliseconds

A common source of confusion: some systems use seconds since epoch, others use milliseconds. The difference is a factor of 1000:

• Seconds (10 digits): 1704067200 — Used by Unix/Linux systems, PHP, Python's time.time(), most databases.
• Milliseconds (13 digits): 1704067200000 — Used by JavaScript's Date.now(), Java's System.currentTimeMillis(), many APIs.

If you get a date in the year 53000 or 1970, you probably mixed up seconds and milliseconds. A 13-digit number interpreted as seconds gives a date far in the future. A 10-digit number interpreted as milliseconds gives a date in January 1970.

Quick check: if the number has 10 digits, it is seconds. If it has 13 digits, it is milliseconds. Our converter handles both automatically.

Converting Timestamps in Code

Every programming language provides timestamp conversion functions:

JavaScript

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

// Timestamp to date
new Date(1704067200 * 1000);

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

Python

import datetime, time

# Current timestamp
time.time()

# Timestamp to datetime
datetime.datetime.fromtimestamp(1704067200, tz=datetime.timezone.utc)

# Datetime to timestamp
datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc).timestamp()

PHP

// Current timestamp
time();

// Timestamp to date string
date('Y-m-d H:i:s', 1704067200);

// Date string to timestamp
strtotime('2024-01-01 00:00:00');

SQL (PostgreSQL)

-- Timestamp to date
SELECT to_timestamp(1704067200);

-- Date to timestamp
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2024-01-01 00:00:00');

The Year 2038 Problem

Unix timestamps stored as 32-bit signed integers can represent dates up to January 19, 2038, at 03:14:07 UTC. After that, the integer overflows and wraps to a negative number, which the system interprets as December 13, 1901.

This is the Y2K38 problem, sometimes called the "Unix Millennium Bug." It affects:

• Older embedded systems and IoT devices using 32-bit processors
• Legacy databases with 32-bit integer timestamp columns
• Older file systems (ext2, FAT32) with 32-bit timestamps
• C programs using the traditional time_t type on 32-bit systems

The fix is straightforward: use 64-bit integers. Modern operating systems, databases, and programming languages have already made this transition. A 64-bit signed integer can represent dates until approximately 292 billion years from now, which should suffice.

If you maintain legacy systems, check whether your timestamp fields are 32-bit. 2038 is close enough that migration should be on your roadmap.

Practical Tips for Working with Timestamps

• Always store in UTC. Convert to local time only at the display layer. Storing local times creates bugs when time zones change (and they do — governments adjust DST rules regularly).
• Use millisecond precision when you need it. For user-facing events (page loads, button clicks), millisecond timestamps capture meaningful timing differences. For daily logs, seconds are sufficient.
• Validate timestamp ranges. A timestamp of 0 means January 1, 1970. A negative timestamp means before 1970. If your application only deals with recent dates, validate that timestamps fall within a reasonable range.
• Be careful with daylight saving time. Converting a UTC timestamp to local time handles DST automatically if you use proper time zone libraries. Rolling your own DST logic is a reliable source of bugs.
• Document your format. When an API returns created_at: 1704067200, document whether that is seconds or milliseconds. When in doubt, include the unit in the field name: created_at_ms or created_at_unix.

Convert timestamps instantly with our Unix Timestamp Converter. For related developer guides, see our JSON formatting best practices and Base64 encoding guide.