What is a Unix Timestamp?

Dig into any database, API payload, or system log and you'll find integers where dates should be. No "July 6, 2026" strings - just a number like 1751788800. That number is a Unix timestamp (also called epoch time or POSIX time): the count of seconds since Thursday, January 1, 1970, 00:00:00 UTC.

Simple concept, but translating that single integer across languages, operating systems, and timezones is a reliable source of bugs. You can quickly convert any epoch value with our free Unix Timestamp Converter - here's what you need to know to avoid the common traps.

Seconds vs. Milliseconds: The "Off-by-1000" Error

Confusing seconds with milliseconds is the single most common timestamp bug. The result: dates that render as January 1, 1970 or jump thousands of years into the future.

You can often determine the precision scale of a timestamp just by counting its digits:

  • Seconds: 10 digits (e.g., 1735689600). The standard for Linux coreutils, PHP time(), and most SQL timestamp columns.
  • Milliseconds: 13 digits (e.g., 1735689600000). The standard for JavaScript's Date.now(), Java System.currentTimeMillis(), and most frontend frameworks.
  • Microseconds: 16 digits. Common in PostgreSQL timestamps and Python high-resolution logs.
  • Nanoseconds: 19 digits. Used in Go time.Now().UnixNano() and high-frequency trading platforms.

When passing a timestamp between a backend API (which might send seconds) and a JavaScript frontend (which expects milliseconds), always ensure you multiply by 1000.

Code Snippets for Standard Environments

Here are reliable ways to convert Unix time in popular languages:

JavaScript (ES6)

// Get Current Unix Time in Seconds
const epochSeconds = Math.floor(Date.now() / 1000);

// Convert Epoch Seconds to standard JS Date object
const parsedDate = new Date(1735689600 * 1000);

Python 3

import time
from datetime import datetime, timezone

# Get Current Epoch Seconds
current_epoch_seconds = int(time.time())

# Convert Unix Epoch Seconds to Timezone-Aware UTC Datetime
utc_dt = datetime.fromtimestamp(1735689600, tz=timezone.utc)

Go (1.17+)

package main

import (
	"fmt"
	"time"
)

func main() {
	// Get Current Unix Time in distinct scales
	now := time.Now()
	seconds := now.Unix()
	milliseconds := now.UnixMilli() 

<TryTool tool="timestamp" />

	// Serialize time.Time to RFC 3339 layout
	parsedTimeSec := time.Unix(1735689600, 0)
	fmt.Println(parsedTimeSec.Format(time.RFC3339))
}

PostgreSQL

-- Get Current Epoch Seconds
SELECT EXTRACT(EPOCH FROM now());

-- Convert Epoch Seconds to TIMESTAMPTZ
SELECT TO_TIMESTAMP(1735689600);

The Year 2038 Problem (Y2K38)

On Tuesday, January 19, 2038, at 03:14:07 UTC, software systems around the world will face the Y2K38 problem, also known as the "Epochalypse".

Systems that store Unix epoch seconds as signed 32-bit integers will reach their maximum limit: 2,147,483,647. At 03:14:08 UTC, the integer overflows and the sign bit flips to negative. This will cause the system clock to instantly jump back to December 13, 1901.

Modern 64-bit operating systems use a signed 64-bit integer (extending the limit to hundreds of billions of years), but the problem remains real for legacy environments. A common bottleneck is MySQL's native TIMESTAMP data type, which stores values as a 32-bit signed integer and caps out at 2038.

If you're running MySQL tables with TIMESTAMP columns, migrate them to DATETIME or BIGINT before the cutoff.

Pre-1970 Timestamps

What about dates before 1970? Unix time handles historical calculations proleptically by using negative integers. For example, a timestamp value of -86400 represents December 31, 1969, at 00:00:00 UTC. However, systems that use unsigned integers to avoid the Y2K38 problem completely lose the ability to represent any date prior to 1970.

Always verify your timestamp format and test integrations before pushing to production. If you need to debug or translate epoch values without sending data to third-party servers, try our Unix Timestamp Converter.