Epoch / Unix Timestamp Converter: The Complete Guide

What is Epoch / Unix Time?

Unix time (also known as POSIX time or epoch time) is a system for describing points in time. It is the number of seconds that have elapsed since the Unix epoch: January 1, 1970, at 00:00:00 UTC (excluding leap seconds).

This simple integer-based representation is the de facto standard for timekeeping in almost all modern operating systems, databases, APIs, and programming languages. Instead of dealing with complex calendar strings, computers represent time as a single number that increases by one every second.

# The current Unix timestamp
# As of June 17, 2026 it would be approximately:
1781700000

The beauty of Unix time is its simplicity: it is timezone-independent (always UTC), easy to compare (a larger number means a later date), and trivial to store in databases as an integer column.

Seconds vs. Milliseconds

A common source of confusion is the difference between timestamps in seconds and milliseconds:

A millisecond timestamp is exactly 1000 times larger than its second counterpart. For example, the epoch in seconds is 0, but in milliseconds it is 0 as well — but for any date after the epoch, the millisecond value is three orders of magnitude greater.

// Seconds: 1700000000
// Milliseconds: 1700000000000
// The millisecond value = seconds × 1000

Common Epoch Reference Table

Here are some notable timestamps for quick reference. Memorize a few of these so you can quickly sanity-check any timestamp you encounter:

How to Convert Timestamps

Timestamp to Date

To convert a Unix timestamp to a human-readable date, you need to know whether the value is in seconds or milliseconds. Once confirmed, multiply or divide by 1000 accordingly, then convert using your language's standard library:

// JavaScript
new Date(1700000000 * 1000).toUTCString()
// "Tue, 14 Nov 2023 22:13:20 GMT"

# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1700000000, tz=timezone.utc)
# datetime.datetime(2023, 11, 14, 22, 13, 20, tzinfo=datetime.timezone.utc)

Date to Timestamp

Going the other direction is equally straightforward. Most languages provide a method to get the current or calculated timestamp:

// JavaScript (milliseconds)
Date.now() // 1700000000000

// JavaScript (seconds)
Math.floor(Date.now() / 1000) // 1700000000

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

Timezone Handling & UTC

The Unix timestamp is always in UTC. It represents the same moment in time regardless of where you are in the world. When you convert a timestamp to a calendar date, you must decide which timezone to display it in.

This is why our Epoch Converter shows both UTC and Local time side by side. The same timestamp of 1700000000 represents:

When storing timestamps, always store as UTC. Convert to local time only when displaying to users.

Epoch in Programming Languages

Here is how to work with Unix timestamps in popular programming languages:

The Year 2038 Problem

Just as Y2K was a concern in the late 1990s, the Year 2038 problem looms for systems that store Unix time as a signed 32-bit integer. The maximum value for a signed 32-bit integer is 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC. One second later, the value overflows to a negative number, causing systems to interpret the date as 1901 instead of 2038.

Most modern systems have already migrated to 64-bit integers (which can represent dates billions of years into the future), but embedded devices, legacy databases, and older file systems may still be vulnerable.

To check if a system is vulnerable, look at how it stores time values. A 64-bit timestamp can represent dates up to roughly 292 billion years into the future — more than enough for any practical application.

Practical Examples

Debugging API Responses

REST APIs commonly return timestamps in epoch format. When debugging, you need to quickly convert these to understand when events occurred:

// API response
{
  "userId": 42,
  "createdAt": 1700000000,
  "lastLogin": 1705000000
}

Using our Epoch Converter, paste 1700000000 to see it is November 14, 2023, and 1705000000 is January 11, 2024.

Calculating Time Differences

Since timestamps are just numbers, you can subtract them to get the exact elapsed duration:

let start = 1699000000;
let end = 1699086400;
let diff = end - start; // 86400 seconds = 1 day

Setting Expiration Dates

When implementing token expiration or time-limited access, calculate future timestamps:

// Token expires in 7 days
let now = Math.floor(Date.now() / 1000);
let expires = now + (7 * 24 * 60 * 60);
// expires = current timestamp + 604800 seconds

Best Practices

• Always use UTC: Store and transmit timestamps in UTC. Only convert to local time for display.
• Be explicit about units: API contracts should document whether timestamps are in seconds or milliseconds. A naming convention like created_at (seconds) vs. created_at_ms (milliseconds) helps.
• Use 64-bit integers: Avoid the 2038 problem by storing timestamps in 64-bit (BIGINT) columns.
• Handle leap seconds gracefully: Unix time ignores leap seconds. Be aware that the real UTC time and Unix time may diverge by up to 27 seconds.
• Validate input: When accepting timestamps from users or APIs, validate the range. A timestamp of 0 is the epoch, negative values are before 1970.
• Prefer ISO 8601 for APIs: For human-readable APIs, consider sending both the epoch timestamp and the ISO 8601 string so consumers can choose their preference.