Unix Timestamp Converter

What Is a Unix Timestamp?

A Unix timestamp is a single integer representing the number of seconds that have elapsed since the Unix epoch: January 1, 1970, at 00:00:00 Coordinated Universal Time (UTC). It is also called POSIX time, Unix time, or epoch time. The choice of 1970 was a practical convention made by the designers of the Unix operating system at Bell Labs. At the time, 1971 was the current year and 1970 was a recent, round starting point that fit comfortably within the integer sizes of the era. Unix timestamps are timezone-independent by definition. The same integer value describes the exact same moment in time regardless of where in the world you are. Local time zones are only applied when formatting a timestamp for human display.

Seconds vs. Milliseconds vs. Microseconds

The number of digits in a Unix timestamp tells you its precision. A 10-digit number represents seconds (e.g. 1717200000). A 13-digit number represents milliseconds, meaning the value has been multiplied by 1,000 (e.g. 1717200000000). A 16-digit number represents microseconds, multiplied by 1,000,000 (e.g. 1717200000000000). Different programming environments default to different precisions. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds. Python's time.time() returns a floating-point number of seconds. Go's time.Now().Unix() returns whole seconds while time.Now().UnixMilli() returns milliseconds. Most Unix system calls and database TIMESTAMP columns operate in whole seconds. When integrating systems across languages, always verify the unit before doing arithmetic to avoid off-by-1000 or off-by-1,000,000 errors.

• •10 digits: seconds precision (Unix, Python, Go, PHP, Ruby, C, Bash)
• •13 digits: milliseconds precision (JavaScript, Java, Kotlin, Swift)
• •16 digits: microseconds precision (Python time.time_ns() / 1000, PostgreSQL EXTRACT EPOCH with microsecond columns)
• •19 digits: nanoseconds (Go time.Now().UnixNano(), Rust SystemTime)

The Year 2038 Problem

Many legacy systems store Unix timestamps as a signed 32-bit integer. The maximum value a signed 32-bit integer can hold is 2,147,483,647. That value corresponds to January 19, 2038, at 03:14:07 UTC. One second later the integer overflows and wraps around to the largest negative value, which most software would interpret as December 13, 1901. This is directly analogous to the Y2K problem. The correct fix is to switch to a 64-bit signed integer for time storage, which can represent dates hundreds of billions of years into the future. Modern 64-bit operating systems and languages already use 64-bit time_t by default. The remaining risk is in embedded systems, legacy databases, and old C code compiled for 32-bit targets that has not been updated. If you maintain infrastructure that will still be running in 2038, auditing your time storage types now is worthwhile.

Leap Seconds and UTC vs. Unix Time

UTC is occasionally adjusted by inserting a leap second to keep civil time synchronized with the Earth's slightly irregular rotation. Since 1972, about 27 leap seconds have been added. Unix time, however, does not account for leap seconds. The POSIX standard defines Unix time as if every day contains exactly 86,400 seconds, which means Unix time is not a perfect linear representation of UTC. In practice, during a leap second the Unix clock either repeats the same second twice (on systems using a step adjustment) or smears the extra time across a window of minutes (Google and Amazon use a smear approach). For most applications this distinction is irrelevant. For sub-second financial systems, astronomical calculations, or GPS-correlated logging, you need to be aware that the difference between UTC and Unix time grows by one second each time a leap second is inserted. The International Earth Rotation Service (IERS) announces upcoming leap seconds in advance.

Common Reference Values

When working with durations in Unix time it is useful to know the number of seconds in common time intervals. These values are exact except for months and years, which vary.

• •1 minute = 60 seconds
• •1 hour = 3,600 seconds
• •1 day = 86,400 seconds
• •1 week = 604,800 seconds
• •1 month (average) = approximately 2,629,746 seconds (365.2425 days / 12)
• •1 year (average Gregorian) = approximately 31,556,952 seconds (365.2425 days)
• •1 year (common, non-leap) = 31,536,000 seconds (365 days exactly)
• •1 year (leap) = 31,622,400 seconds (366 days exactly)

Get & convert the Unix timestamp in any language

// current epoch (seconds)
const epoch = Math.floor(Date.now() / 1000);

// epoch → date
const date = new Date(epoch * 1000).toISOString();

// current epoch (seconds)
import time; epoch = int(time.time())

// epoch → date
from datetime import datetime, timezone; date = datetime.fromtimestamp(epoch, tz=timezone.utc).isoformat()

// current epoch (seconds)
$epoch = time();

// epoch → date
$date = gmdate('Y-m-d\TH:i:s\Z', $epoch);

// current epoch (seconds)
long epoch = Instant.now().getEpochSecond();

// epoch → date
String date = Instant.ofEpochSecond(epoch).toString();

// current epoch (seconds)
epoch := time.Now().Unix()

// epoch → date
date := time.Unix(epoch, 0).UTC().Format(time.RFC3339)

// current epoch (seconds)
epoch = Time.now.to_i

// epoch → date
date = Time.at(epoch).utc.iso8601

// current epoch (seconds)
long epoch = DateTimeOffset.UtcNow.ToUnixTimeSeconds();

// epoch → date
string date = DateTimeOffset.FromUnixTimeSeconds(epoch).UtcDateTime.ToString("o");

// current epoch (seconds)
let epoch = std::time::SystemTime::now().duration_since(std::time::UNIX_EPOCH).unwrap().as_secs();

// epoch → date
// Use the `chrono` crate: let date = chrono::DateTime::from_timestamp(epoch as i64, 0).unwrap().to_rfc3339();

// current epoch (seconds)
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT AS epoch;  -- PostgreSQL

// epoch → date
SELECT TO_TIMESTAMP(epoch) AT TIME ZONE 'UTC' AS date;  -- PostgreSQL

// current epoch (seconds)
epoch=$(date +%s)

// epoch → date
date=$(date -u -d "@$epoch" '+%Y-%m-%dT%H:%M:%SZ')  # GNU date; macOS: date -u -r "$epoch" '+%Y-%m-%dT%H:%M:%SZ'

Frequently asked questions