Epoch Timestamp Converter

Convert Unix Timestamps to Dates and Back with Timezone Support

Convert between epoch timestamps and readable dates instantly. Supports multiple date formats, timezones, and both unix time to date and date to timestamp conversions.

Understanding Time Formats

What is Unix Time?

Unix time (also known as POSIX time or epoch time) represents the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC, excluding leap seconds. It‘s widely used in computer systems for date and time representation.

What is Epoch Time?

Epoch time is essentially the same as Unix time. It refers to the point in time (January 1, 1970) from which time is measured. The epoch serves as a reference point for computer systems to calculate dates and times.

Milliseconds vs. Seconds

Unix timestamps can be represented in either seconds or milliseconds:

  • Unix timestamp in seconds: 1620000000
  • Unix timestamp in milliseconds: 1620000000000

Most systems use seconds, but languages like JavaScript use milliseconds internally.

Common Time Formats Compared

FormatExampleUse Case
Unix Timestamp1620000000Programming, databases
ISO 86012021-05-03T00:00:00ZInternational standard, APIs
RFC 2822Mon, 03 May 2021 00:00:00 +0000Email headers
Human ReadableMay 3, 2021User interfaces

Unix Epoch Reference

Everything a developer needs to work with epoch timestamps confidently — language snippets, format conversions, common gotchas, and example timestamps you can copy directly into your tests.

Get the Current Unix Timestamp in Any Language

The Unix epoch is a language-agnostic concept, but every runtime exposes it slightly differently. Here are current-timestamp snippets in the languages developers ask about most often.

JavaScript / TypeScript

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

// Milliseconds (JS default)
Date.now()

// Convert timestamp to Date
new Date(timestamp * 1000)

Python

import time
from datetime import datetime, timezone

# Current epoch (float seconds)
time.time()

# Integer seconds
int(time.time())

# Timezone-aware conversion
datetime.fromtimestamp(ts, tz=timezone.utc)

Bash / Shell

# Current epoch
date +%s

# Epoch -> human (GNU date)
date -d @1700000000

# Epoch -> human (BSD/macOS)
date -r 1700000000

# Human -> epoch
date -d "2026-01-01 00:00:00 UTC" +%s

SQL

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::bigint;
SELECT to_timestamp(1700000000);

-- MySQL
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1700000000);

-- SQLite
SELECT strftime('%s', 'now');

Go

import "time"

// Current epoch in seconds
time.Now().Unix()

// Milliseconds
time.Now().UnixMilli()

// Epoch -> time.Time
time.Unix(1700000000, 0)

Rust

use std::time::{SystemTime, UNIX_EPOCH};

let secs = SystemTime::now()
    .duration_since(UNIX_EPOCH)
    .unwrap()
    .as_secs();

Ruby

# Current epoch
Time.now.to_i

# Milliseconds
(Time.now.to_f * 1000).to_i

# Epoch -> Time
Time.at(1700000000)

C# / .NET

// .NET 6+ — current epoch seconds
DateTimeOffset.UtcNow.ToUnixTimeSeconds()

// Milliseconds
DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()

// Epoch -> DateTimeOffset
DateTimeOffset.FromUnixTimeSeconds(1700000000)

Java

// Java 8+ recommended
Instant.now().getEpochSecond()
Instant.now().toEpochMilli()

// Epoch -> Instant
Instant.ofEpochSecond(1700000000)

PHP

// Current epoch
time();

// Milliseconds
(int)(microtime(true) * 1000);

// Epoch -> human
date('Y-m-d H:i:s', 1700000000);

Common Timestamp Formats Side by Side

One moment in time can be written in many ways. Picking the wrong format is one of the most common interoperability bugs in APIs. The reference timestamp below is 1700000000 — Tuesday, 14 November 2023, 22:13:20 UTC.

FormatExampleWhen to use
Unix seconds1700000000Storage, databases, OS APIs, cron, JWT exp/iat
Unix milliseconds1700000000000JavaScript, Java, mobile SDKs, event streams
Unix microseconds1700000000000000High-frequency systems, distributed tracing
ISO 8601 (UTC)2023-11-14T22:13:20ZREST/GraphQL APIs, logs, machine-readable
ISO 8601 (offset)2023-11-14T17:13:20-05:00Preserving local context (calendar events)
RFC 2822Tue, 14 Nov 2023 22:13:20 +0000Email headers (Date:), HTTP headers
RFC 3339 (subset of 8601)2023-11-14T22:13:20.000ZInternet protocols requiring strict parsing
Locale (US human)Nov 14, 2023, 10:13 PMUI display only — never store this

Gotchas That Bite Developers

Seconds vs. milliseconds — the #1 mistake

JavaScript's Date.now() returns milliseconds. Most other languages return seconds. If a date shows as 1970-01-20 when you expected today, you divided by 1000 too many times. If it shows as 50000+ AD, you multiplied. Always document whether your API uses seconds or milliseconds, and prefer ISO 8601 on the wire to avoid the question entirely.

Leap seconds

POSIX defines Unix time to ignore leap seconds — every day is exactly 86,400 seconds, even on the ~27 days in history when UTC actually had 86,401. For most applications this is invisible. For NTP servers, financial trading, or anything with sub-second SLAs, "smeared" clocks (Google, Amazon, Meta Time) distribute the leap second across hours so timestamps remain monotonic.

Daylight saving time (DST)

Unix timestamps are immune to DST because they are UTC. DST is a display concern. If a recurring event is "every Monday at 9 AM in New York," you must store it as a wall-clock time + IANA timezone (e.g. America/New_York), not as a Unix timestamp — otherwise the meeting will jump an hour twice a year.

The Year 2038 problem

A signed 32-bit integer overflows at 2147483647, which is 2038-01-19 03:14:07 UTC. Any code, embedded device, file format, or database column still using INT for timestamps will roll over to 1901. Use 64-bit integers everywhere — they overflow in the year 292,277,026,596 AD.

Negative timestamps

Timestamps before 1970-01-01 UTC are negative. They're valid in most modern libraries but many legacy systems treat them as errors or wrap around. If you're storing historical dates (birthdays, archives), prefer a date column over an epoch.

String "timestamps" vs. integers

Many APIs send epoch values as JSON strings ("1700000000") to avoid precision loss on 64-bit values in JavaScript, where numbers are IEEE-754 doubles. Always parse explicitly — silent string-to-number coercion has caused outages.

Notable Epoch Timestamps

Handy values to test boundary conditions in your code.

TimestampDate (UTC)Why it matters
01970-01-01 00:00:00The Unix epoch itself
10000000002001-09-09 01:46:40First 10-digit timestamp ("Unix billennium")
12345678902009-02-13 23:31:30Memorable monotonic sequence — celebrated by Unix enthusiasts
15000000002017-07-14 02:40:00Convenient round value for test fixtures
21474836472038-01-19 03:14:07Year-2038 overflow boundary (signed 32-bit max)
-22089888001900-01-01 00:00:00NTP epoch offset (NTP counts from 1900, not 1970)

Best Practices

  • Store UTC, display local. Persist Unix timestamps or ISO 8601 with a Zsuffix; convert to the user's zone only at render time.
  • Pick a precision and document it. Mixing seconds and milliseconds in the same codebase causes 1000× bugs that are silent in dev and catastrophic in production.
  • Use IANA timezone names, not offsets. America/New_York survives DST changes; UTC-05:00doesn't.
  • Use 64-bit integers. The 2038 cliff is closer than you think, and embedded devices ship with multi-decade lifespans.
  • Validate input ranges. Reject timestamps that fall outside a sane window (e.g. 2000–2100 for booking systems) — most bad data comes from unit-confusion bugs upstream.
  • Prefer ISO 8601 on the wire.It's human-readable, sorts lexicographically, self-documents timezone, and survives every JSON parser without precision loss.

Epoch timestamp FAQs

Common questions about Unix timestamps, epoch time, and how to use this converter.