Unix Timestamp Converter Guide: Epoch Time Explained

What Is a Unix Timestamp?

A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC — the "Unix Epoch." It's a single integer with no timezone information embedded, which makes it the universal format for time in distributed systems.

1709296000  →  2024-03-01 08:00:00 UTC

Every modern programming language, database, and operating system can produce and consume Unix timestamps. They survive serialization, database storage, and network transfer without losing precision or gaining timezone ambiguity — unlike locale-aware date strings.

Seconds vs Milliseconds — The Most Common Confusion

Two conventions exist and they're easy to confuse:

// Seconds (Unix standard)
Math.floor(Date.now() / 1000)  // → 1709296000

// Milliseconds (JavaScript default)
Date.now()  // → 1709296000000

// Milliseconds to Date object
new Date(1709296000000)  // → Fri Mar 01 2024 08:00:00 GMT+0000

// Seconds to Date object — must multiply
new Date(1709296000 * 1000)  // → Fri Mar 01 2024 08:00:00 GMT+0000

Our converter auto-detects the scale: 10-digit numbers are treated as seconds, 13-digit numbers as milliseconds.

Classic bug: passing a seconds-based JWT exp value directly to JavaScript's new Date() without multiplying by 1000:

// Wrong — creates a date in 1970 (microseconds from epoch)
const expiry = new Date(1709296000);  // Jan 20 1970 — token never expires!

// Correct
const expiry = new Date(1709296000 * 1000);  // Mar 01 2024

JWT Claims and Timestamp Validation

JWT tokens use Unix timestamps (seconds) for three standard claims:

Paste a timestamp from any of these claims into our converter to see the exact datetime in both UTC and your local timezone. This is the fastest way to diagnose 401 Unauthorized errors caused by expired tokens — is exp in the past?

Use our JWT Debugger to decode the full token and see all claims with timestamps pre-converted.

Timezone Pitfalls in Backend Systems

Unix timestamps are timezone-neutral, but converting them to human-readable dates is not. Common sources of bugs:

Server timezone vs user timezone

Your AWS EC2 instance runs in UTC. Your database stores timestamps as Unix integers. Your API returns them as Unix integers. Your frontend converts them to local time for display. If any step in this chain assumes the wrong timezone, users see times that are hours off.

Best practice: store as Unix timestamps (timezone-neutral), transmit as Unix timestamps, convert to local time only at the display layer — in the browser, using the user's device timezone.

Daylight Saving Time (DST) gaps

In DST-observing timezones, clocks spring forward — times between 2:00 AM and 3:00 AM don't exist on one day per year. If you're doing date arithmetic in local time, you can create timestamps for non-existent times. Doing arithmetic in UTC (Unix timestamps) avoids this entirely.

The "off by one hour" bug

A server logs an event at 2024-03-10 02:30:00 UTC. A developer in EST (UTC-5) reads this as 9:30 PM the previous day. Another developer in CET (UTC+1) reads it as 3:30 AM. Using our converter with explicit UTC display eliminates this confusion.

Comparing Timestamps in Log Files

When debugging distributed systems, you'll often have timestamps from multiple services with different formats. Use our Text Diff Checker to compare log snippets side-by-side after normalizing all timestamps to Unix format (or all to the same human-readable UTC format).

A sequence like this:

Service A: 1709296000 (request received)
Service B: 1709296002 (request processed)
Service C: 1709296045 (response sent)

Shows a 43-second gap between B and C — the problem is immediately visible when timestamps are on the same scale.

Generating Timestamps for Testing

For creating test data with realistic timestamps:

// One week ago
Math.floor(Date.now() / 1000) - (7 * 24 * 60 * 60)

// 15 minutes from now (JWT exp for short-lived token)
Math.floor(Date.now() / 1000) + (15 * 60)

// Start of today in UTC
Math.floor(new Date().setUTCHours(0,0,0,0) / 1000)

Combine with our Cron Generator when building scheduled jobs that need to validate or produce timestamps — knowing the next-run Unix timestamp helps verify your scheduler is configured correctly.

Database Timestamp Storage

The 2038 problem: MySQL's TIMESTAMP type uses a 32-bit signed integer, which overflows on January 19, 2038 (Unix timestamp 2147483647). MySQL 8.0+ and most modern databases handle this, but legacy systems may not. Store as BIGINT or TIMESTAMPTZ for future safety.

Converting Other Date Formats

Common date formats you'll encounter and how to convert them:

// ISO 8601 string → Unix timestamp (seconds)
Math.floor(new Date("2024-03-01T08:00:00Z").getTime() / 1000)  // → 1709280000

// RFC 2822 (email format) → Unix timestamp
Math.floor(new Date("Fri, 01 Mar 2024 08:00:00 +0000").getTime() / 1000)

// Local date string → Unix timestamp (timezone-dependent!)
Math.floor(new Date("2024-03-01").getTime() / 1000)  // Depends on device timezone!

The last example is the trap — new Date("2024-03-01") is interpreted as UTC midnight, but new Date("2024-03-01 00:00:00") is interpreted as local midnight in most browsers. Always include explicit timezone information in date strings you parse.

Pair with our UUID Generator when building audit log records that combine unique identifiers with timestamps — the combination of UUID + Unix timestamp gives you a globally unique, sortable, human-debuggable record ID.