What is the difference between seconds and milliseconds in a timestamp?

A 10-digit Unix timestamp represents seconds. A 13-digit timestamp represents milliseconds (1000x more precise). JavaScript's Date.now() returns milliseconds, while most Unix systems and languages default to seconds. This converter auto-detects the format based on the number of digits.

What is the Year 2038 problem?

Systems that store Unix timestamps as a signed 32-bit integer will overflow on January 19, 2038 at 03:14:07 UTC (timestamp 2147483647). Modern systems use 64-bit integers, which won't overflow until the year 292 billion.

How do I get the current Unix timestamp in different programming languages?

Why does my timestamp show the wrong time?

Unix timestamps are always UTC-based. If your converted time looks off by a fixed number of hours, you're likely confusing UTC with your local timezone. Use the timezone selector to convert to your local time, or make sure you're comparing to UTC.

// epoch converter

Unix Timestamp Tools

Q: What is a Unix timestamp?

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC (the Unix Epoch). It is a timezone-independent way to represent a specific point in time, widely used in databases, APIs, server logs, and programming languages.

Current Unix Time

// 01 — Epoch → Human-readable date

Unix Timestamp

Timezone

Supports seconds (10 digits), milliseconds (13), microseconds (16), nanoseconds (19) — auto-detected

Invalid timestamp. Please enter a numeric Unix timestamp.

UTC / GMT

—

Local Time

—

Selected Timezone

—

Relative

—

ISO 8601

—

Day of week / Week

—

// 02 — Date → Epoch timestamp

Year

Month

Day

Hour

Min

Sec

Timezone

Epoch (seconds)

—

Epoch (milliseconds)

—

ISO 8601

—

Day of week

—

Please check the values — year (1970–9999), month (1–12), day (1–31), hour (0–23), min/sec (0–59).

Or paste a date string:

Could not parse that date string.

// 03 — Epoch range for year / month / day

Year

Month (optional)

Day (optional)

Start (UTC)

—

End (UTC)

—

Start timestamp

—

End timestamp

—

// 04 — Convert seconds to years, months, days, hours, minutes

Seconds

86400 = 1 day · 604800 = 1 week · 2629800 = ~1 month · 31536000 = 1 year

// 05 — Batch timestamp conversion

One timestamp per line. Paste from logs, databases, or APIs.

Timestamps (one per line)

Output timezone

What is a Unix timestamp?

A Unix timestamp — also called epoch time, POSIX time, or Unix time — is a single integer representing the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC. This reference point is known as the Unix Epoch, and it was chosen by early Unix developers at Bell Labs as a convenient starting point close to when the operating system was being built.

The fundamental advantage of Unix timestamps is that they are completely timezone-independent. The integer 1700000000 means exactly one thing — November 14, 2023 at 22:13:20 UTC — regardless of whether you're reading it in Oslo, Tokyo, or New York. There's no ambiguity, no daylight saving time to account for, and no locale-specific formatting to parse. It's just a number.

You'll encounter Unix timestamps in almost every layer of modern software: REST API responses (fields like created_at, expires_at, last_modified), SQL database columns typed as INTEGER or BIGINT, JWT tokens (the iat and exp claims), server log files, file system metadata, Git commits, Kafka messages, AWS Lambda events, Stripe payments, and GitHub webhook payloads. Understanding how to read and convert them is a core skill for any developer or system administrator.

Seconds, milliseconds, microseconds — how to tell them apart

The single most common source of confusion with Unix timestamps is precision. Not all timestamps count seconds — JavaScript and Java default to milliseconds, PostgreSQL stores microseconds internally, and Go can produce nanosecond timestamps. If you paste a timestamp into a converter and get a date in 1970 or far in the future, the precision is wrong. This converter auto-detects based on digit count.

10 digits = seconds

The standard Unix format. Example: 1700000000. Used by Python's time.time(), PHP's time(), Go's time.Now().Unix(), Ruby's Time.now.to_i, C's time(NULL), MySQL's UNIX_TIMESTAMP(), and Bash's date +%s.

13 digits = milliseconds

JavaScript's default. Example: 1700000000000. Returned by Date.now(), new Date().getTime(), Java's System.currentTimeMillis(), and most browser APIs. Divide by 1000 to get seconds.

16 digits = microseconds

Used in PostgreSQL's internal timestamptz storage, some Linux kernel interfaces, and Python's time.time_ns() / 1000. Example: 1700000000000000. Divide by 1,000,000 to get seconds.

19 digits = nanoseconds

Used in Go's time.Now().UnixNano(), Rust's SystemTime::now(), and high-frequency trading systems. Example: 1700000000000000000. Divide by 1,000,000,000 to get seconds.

A quick rule of thumb: if your timestamp shows a date in 1970, you're treating milliseconds as seconds. If it shows a date far in the future (like 2527), you're treating seconds as milliseconds. Fix it by multiplying or dividing by 1000.

Get the current Unix timestamp in any language

The live timestamp at the top of this page shows the current Unix time — updated every second. Here's how to get the same value in code:

JavaScript / Node.js

Math.floor(Date.now() / 1000)
In milliseconds: Date.now()

Python

import time
int(time.time())
In ms: int(time.time() * 1000)

PHP

time()
With microseconds: microtime(true)

Go

time.Now().Unix()
In ms: time.Now().UnixMilli()

Java / Kotlin

Instant.now().getEpochSecond()
In ms: System.currentTimeMillis()

Ruby

Time.now.to_i
In ms: Time.now.to_f * 1000

Rust

SystemTime::now()
.duration_since(UNIX_EPOCH)
.unwrap().as_secs()

C# / .NET

DateTimeOffset.UtcNow
.ToUnixTimeSeconds()

MySQL

SELECT UNIX_TIMESTAMP();

PostgreSQL

SELECT EXTRACT(EPOCH FROM NOW())::INT;

SQLite

SELECT unixepoch('now');
or strftime('%s','now')

Bash / Shell

date +%s
In ms: date +%s%3N

Convert Unix timestamp to date — code examples

Converting a Unix timestamp to a human-readable date requires knowing the precision (seconds vs milliseconds) and the target timezone. Here are the most reliable patterns in each major language:

JavaScript

// Seconds timestamp
new Date(ts * 1000).toISOString()

// Milliseconds timestamp
new Date(ts).toISOString()

// With timezone
new Intl.DateTimeFormat('en-GB',
{ timeZone: 'Europe/Oslo' })
.format(new Date(ts * 1000))

Python

from datetime import datetime, timezone

# UTC (recommended)
datetime.fromtimestamp(ts,
tz=timezone.utc)

# Format as string
datetime.utcfromtimestamp(ts)
.strftime('%Y-%m-%d %H:%M:%S')

PHP

// UTC
gmdate('Y-m-d H:i:s', $ts)

// Local
date('Y-m-d H:i:s', $ts)

// With timezone
$dt = new DateTime("@$ts");
$dt->setTimezone(
new DateTimeZone('Europe/Oslo'));

MySQL

-- Basic
SELECT FROM_UNIXTIME(1700000000);

-- Formatted
SELECT FROM_UNIXTIME(ts,
'%Y-%m-%d %H:%i:%s');

-- Date to Unix
SELECT UNIX_TIMESTAMP(
'2026-04-17 10:35:00');

PostgreSQL

-- Unix to datetime
SELECT TO_TIMESTAMP(1700000000);

-- With timezone
SELECT TO_TIMESTAMP(ts)
AT TIME ZONE 'Europe/Oslo';

-- Datetime to Unix
SELECT EXTRACT(EPOCH FROM NOW());

Go

t := time.Unix(ts, 0).UTC()

// Format
t.Format(time.RFC3339)

// With timezone
loc, _ := time.LoadLocation(
"Europe/Oslo")
t.In(loc).Format("2006-01-02")

Unix time and timezones

Unix timestamps are always stored as UTC. The timezone only matters when you display the timestamp to a human. The same integer looks different depending on where you are: 1700000000 is 22:13:20 UTC, but 23:13:20 CET (Oslo in winter) and 17:13:20 EST (New York). The underlying value never changes — only the presentation does.

This is why it's best practice to always store timestamps as UTC Unix integers in your database and only convert to local time at the display layer. Mixing timezones in storage leads to subtle bugs that are difficult to track down, especially around daylight saving time transitions.

Common timezone pitfalls: forgetting that JavaScript's new Date() parses strings without a timezone offset as local time, not UTC. Always append a Z to ISO strings (2026-04-17T10:35:00Z) to force UTC parsing. In Python, use timezone-aware datetimes (datetime.now(timezone.utc)) instead of the naive datetime.now() which uses local time.

Useful Unix timestamp reference values

Milestone timestamps

0 = Jan 1, 1970 (the epoch)
1000000000 = Sep 9, 2001
1234567890 = Feb 13, 2009
1500000000 = Jul 14, 2017
1700000000 = Nov 14, 2023
2000000000 = May 18, 2033
2147483647 = Jan 19, 2038 (32-bit max)

Common durations in seconds

1 minute = 60
1 hour = 3,600
1 day = 86,400
1 week = 604,800
1 month ≈ 2,629,800
1 year = 31,536,000
10 years = 315,360,000

Time arithmetic examples

7 days ago: now - 604800
30 days from now: now + 2592000
Start of today (UTC): round down to nearest 86400
JWT expires in 1h: now + 3600
Session timeout 24h: now + 86400

The Year 2038 problem

32-bit signed integers max out at 2,147,483,647 = Jan 19, 2038. Systems storing timestamps as INT32 will overflow. Modern systems use 64-bit integers, extending the range to the year ~292 billion. All new code should use 64-bit types.

ISO 8601 and Unix timestamps

ISO 8601 is the international standard for representing dates and times as strings: 2026-04-17T10:35:00Z. The T separates the date from the time, and Z means UTC (you can also use a numeric offset like +02:00). ISO 8601 is used in JSON APIs, HTML <time> elements, HTTP headers, and log formats.

The relationship between ISO 8601 and Unix timestamps: they represent the same information in different forms. 2026-04-17T10:35:00Z and 1776415200 are the same moment — one is human-readable, the other is machine-efficient. Unix timestamps are better for storage and arithmetic; ISO 8601 strings are better for display and interoperability.

Parse an ISO 8601 string to Unix in JavaScript: Math.floor(new Date('2026-04-17T10:35:00Z').getTime() / 1000). In Python: int(datetime.fromisoformat('2026-04-17T10:35:00+00:00').timestamp()). The date string parser in section 2 above accepts ISO 8601 directly — just paste it in.

Related tools on this site

Frequently asked questions

What is the Unix Epoch and why is it January 1, 1970?

The date was chosen by early Unix developers at Bell Labs in the late 1960s as a convenient round number close to when Unix was being developed. The specific date was somewhat arbitrary — it simply needed to be a fixed, recent point in the past that was easy to work with mathematically. January 1, 1970 was a clean starting point that predated widespread computer adoption, ensuring no real-world timestamps would be negative. It has since become the universal reference for time in computing, used by every major operating system, language runtime, and database.
What is the Year 2038 problem?

Systems that store Unix timestamps as a signed 32-bit integer can only represent values up to 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. After that point, the integer overflows to a large negative number, causing dates to wrap around to 1901. This is a real risk for legacy embedded systems, older databases, and 32-bit Linux installations. Modern 64-bit systems are unaffected — a 64-bit signed integer can represent timestamps until approximately the year 292 billion, making the problem irrelevant for all new software.
Why does my converted timestamp show the wrong time?

There are two common causes. First, check the precision: if your timestamp is 13 digits, it's in milliseconds — pass it to the converter as-is and it will auto-detect correctly, or divide by 1000 if you're doing it in code. Second, check the timezone: Unix timestamps are always UTC internally. If your result is off by a fixed number of hours (like 1, 2, or 5), you're seeing the correct UTC time but expecting local time. Use the timezone selector in the converter to show the result in your local timezone.
What is the difference between Unix time and UTC?

UTC (Coordinated Universal Time) is a time standard — a way of expressing a moment in time with a date, hour, minute, and second. Unix time is a counting system — the number of seconds since a fixed point (January 1, 1970 00:00:00 UTC). They are related but not the same thing. Unix time is defined relative to UTC, but the two diverge slightly because UTC includes leap seconds (which adjust for Earth's irregular rotation) while Unix time does not. Every day in Unix time is exactly 86,400 seconds, even on days when UTC inserts a leap second. This means Unix time is off from true UTC by about 27 seconds as of 2024 — a difference that matters only in extremely high-precision scientific contexts.
Can Unix timestamps represent dates before 1970?

Yes. Negative Unix timestamps represent dates before January 1, 1970. For example, -86400 represents December 31, 1969 at 00:00:00 UTC, and -2208988800 represents January 1, 1900. Most modern programming languages and databases support negative timestamps correctly. Some older systems or libraries may have issues with negative values, particularly those using unsigned integers for timestamp storage.
Do Unix timestamps account for leap seconds?

No. Unix time deliberately ignores leap seconds — every day is treated as exactly 86,400 seconds, even on days when UTC inserts a leap second. This means Unix time is not a perfectly accurate representation of UTC, but it makes time arithmetic much simpler and more predictable. The accumulated difference between Unix time and true UTC is currently about 27 seconds (as of 2024). For the vast majority of applications — web services, databases, APIs — this difference is completely irrelevant. Only scientific instruments, GPS systems, and financial trading infrastructure need to account for it.
How do I compare two timestamps in code?

Since Unix timestamps are plain integers, comparison is trivial: use standard integer comparison operators. To check if event A happened before event B: timestamp_a < timestamp_b. To find events in the last 24 hours: timestamp > (current_time - 86400). To calculate the duration between two events in seconds: end_timestamp - start_timestamp. This simplicity — and the fact that it works identically in every language — is one of the main reasons Unix timestamps are so widely used.
What is a JWT timestamp and how do I decode it?

JSON Web Tokens (JWTs) use Unix timestamps in their payload claims. The most common are: iat (issued at — when the token was created), exp (expiry — when the token becomes invalid), and nbf (not before — the earliest valid time). These are all standard Unix timestamps in seconds. To decode a JWT and read its timestamps, base64-decode the middle section (the payload) and parse the JSON. To check if a JWT is expired: compare the exp claim to the current Unix timestamp — if exp < now, the token has expired.
How should I store timestamps in a database?

Best practice is to store timestamps as UTC Unix integers (BIGINT column) rather than formatted strings or database-specific datetime types. The advantages: integers are compact (8 bytes for BIGINT vs 24+ bytes for a formatted string), sorting and comparison are fast native operations, there's no timezone ambiguity in storage, and the format works identically across all programming languages and database systems. The main alternative — database-native TIMESTAMP or DATETIME types — is also acceptable, but always configure the column to use UTC storage. Never store local time in a database, as daylight saving time transitions will create ambiguous or duplicate timestamps.

What is a Unix timestamp?

Seconds, milliseconds, microseconds — how to tell them apart

10 digits = seconds

13 digits = milliseconds

16 digits = microseconds

19 digits = nanoseconds

Get the current Unix timestamp in any language

JavaScript / Node.js

Python

PHP

Go

Java / Kotlin

Ruby

Rust

C# / .NET

MySQL

PostgreSQL

SQLite

Bash / Shell

Convert Unix timestamp to date — code examples

JavaScript

Python

PHP

MySQL

PostgreSQL

Go

Unix time and timezones

Useful Unix timestamp reference values

Milestone timestamps

Common durations in seconds

Time arithmetic examples

The Year 2038 problem

ISO 8601 and Unix timestamps

Related tools on this site

By language

By database

Conversion guides

SQL guides

Frequently asked questions