Unix timestamp & epoch date converter
Convert Unix epoch timestamps across seconds, milliseconds, microseconds, and nanoseconds into human-readable ISO 8601, UTC, and local time formats with real-time relative countdowns.
How to convert timestamps and dates
- Type or paste a Unix timestamp (10, 13, 16, or 19 digits) into the Timestamp or Date input field. The converter automatically detects the unit and calculates the date.
- Alternatively, paste an ISO 8601 string (e.g.
2026-09-18T14:30:00Z) or date phrase to convert it into raw Unix epoch seconds and milliseconds. - Use the Quick Adjustments buttons (+1 Hour, -1 Hour, +1 Day, Start of Day) to step through time intervals rapidly.
- Click Copy next to any formatted row (ISO 8601, UTC, Local, or Relative) to place the exact date string onto your clipboard.
The Foundations of Unix Epoch Time
Unix time (also known as Epoch time or POSIX time) tracks time as a continuous running integer representing the number of elapsed seconds since the Unix Epoch: 00:00:00 UTC on Thursday, 1 January 1970, not counting leap seconds.
Established during the development of the early Unix operating system at Bell Labs, this linear representation revolutionized computer systems by replacing complex calendar date math (leap years, variable month lengths, local daylight saving adjustments) with simple, monotonically increasing integers. Today, Unix time is the universal foundational metric for distributed logging, database row versioning, cryptographic certificates, and authentication tokens.
Timestamp Units and Integer Digit Lengths
Different programming languages, frameworks, and database engines store Unix timestamps with differing degrees of temporal precision:
| Unit | Digit Length | Multiplier | Standard Systems & Language APIs |
|---|---|---|---|
| Seconds | 10 digits (e.g. 1726670000) | \(1\) | Standard Unix C time_t, Linux kernels, POSIX systems, SQL UNIX_TIMESTAMP(), JWT claims (iat, exp, nbf). |
| Milliseconds | 13 digits (e.g. 1726670000000) | \(10^3\) | JavaScript Date.now(), Java System.currentTimeMillis(), MongoDB BSON Date objects, browser performance timers. |
| Microseconds | 16 digits | \(10^6\) | Python datetime.timestamp(), PostgreSQL timestamp with time zone, high-resolution OS system profiling. |
| Nanoseconds | 19 digits | \(10^9\) | Go time.Now().UnixNano(), Linux CLOCK_REALTIME, distributed tracing telemetry (OpenTelemetry, Zipkin, Jaeger). |
The Year 2038 Problem (Y2038 Bug)
One of the most consequential milestones in computer engineering is the Year 2038 Problem (analogous to the Y2K bug). Legacy 32-bit Unix systems store time_t as a 32-bit signed integer. The maximum integer value a 32-bit signed number can hold is:
2^(31) - 1 = 2,147,483,647
This maximum integer value corresponds exactly to 03:14:07 UTC on Tuesday, 19 January 2038. At the following second, 32-bit systems will suffer an arithmetic integer overflow, wrapping around to a negative integer (-2,147,483,648), which represents 13 December 1901.
Modern 64-bit operating systems, databases, and programming languages use 64-bit signed integers for epoch timestamps. A 64-bit timestamp has a maximum value of \(2^{63}-1\), extending the safe operating horizon approximately 292 billion years into the future.
Language Code Snippets: Working with Unix Timestamps
Converting between timestamps and dates in common programming environments:
- JavaScript / Node.js:
const epochSeconds = Math.floor(Date.now() / 1000);
const date = new Date(epochSeconds * 1000).toISOString(); - Python:
import time, datetime
now_sec = int(time.time())
dt = datetime.datetime.fromtimestamp(now_sec, datetime.timezone.utc) - Go (Golang):
nowSec := time.Now().Unix()
t := time.Unix(nowSec, 0).UTC() - Rust:
use chrono::{DateTime, Utc};
let dt = DateTime::from_timestamp(1726670000, 0).unwrap();
Leap Seconds and Formatting Standards: ISO 8601 vs RFC 2822
Unix time intentionally ignores leap seconds. Instead of inserting a 61st second (23:59:60), the Unix clock steps backward by one second during a leap second event, repeating second 86399. Modern hyperscale infrastructure systems (like Google Cloud and AWS) utilize "leap second smearing," subtly slowing or accelerating server clock frequencies over a 24-hour window to keep systems strictly monotonically synchronized without clock jumps.
When sharing dates across network APIs, two primary formatting standards dominate:
- ISO 8601 / RFC 3339 (e.g.
2026-09-18T18:00:00.000Z): The international gold standard for web APIs, JSON documents, and database storage. It orders units from largest to smallest (year, month, day, hour, minute, second) ensuring alphanumeric sorting corresponds to chronological order. - RFC 2822 / RFC 5322 (e.g.
Fri, 18 Sep 2026 18:00:00 GMT): The historical email and HTTP header timestamp standard (used inDate,Last-Modified, andExpiresheaders).
100% Client-Side Privacy Guarantee
Log entries and trace spans frequently contain proprietary transaction IDs and confidential event timing. DevSandbox evaluates all timestamp conversions, time math, and string formatting locally within your browser tab using native JavaScript Date and Intl APIs. Zero network calls are made, and your timeline data remains private.
Frequently asked questions
What is Unix epoch time?
Unix time is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It is the universal standard for timestamping events in computing.
How does the converter handle seconds vs milliseconds?
10-digit integers are detected as epoch seconds, while 13-digit integers are recognized as milliseconds. The converter also supports 16-digit microseconds and 19-digit nanoseconds.
Does the converter respect my local timezone?
Yes. The converter outputs the date in UTC, ISO 8601, and your browser's local timezone format, along with relative time descriptions.
What is the Year 2038 problem?
Legacy 32-bit systems store timestamps as signed 32-bit integers, which overflow on January 19, 2038 at 03:14:07 UTC. Modern 64-bit systems extend this limit by approximately 292 billion years.
Does Unix time include leap seconds?
No. Unix time intentionally ignores leap seconds by repeating or smearing the 86,400th second of the day during a leap second event.