Developer tool
Unix timestamp converter.
Paste an epoch — seconds or milliseconds, we auto-detect — and see it instantly as ISO 8601, RFC 2822, Discord markdown, and any IANA timezone. Or paste a date and get the epoch back. Daylight saving is applied per time zone; like all Unix time, leap seconds are not counted.
Unix timestamp at 2026-11-05 13:13:47 UTC (live once the page loads)
1793884427
Milliseconds: 1793884427000
Inputs
Edit any field — the others update live. Numbers larger than 1011 are treated as milliseconds.
Enter a value above to see conversions.
Enter a value above to see per-timezone conversions.
About Unix time
Unix time — also called epoch time or POSIX time — is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. It is the lingua franca of timestamps in computing: log files, database columns, JSON APIs, JWT expirations, file metadata, and the kernel's own clock all speak it. A single integer represents an absolute instant in time, independent of timezone, calendar reform, or daylight saving rules.
The format you encounter in the wild is almost always one of two: seconds (the original POSIX definition, used by C's time_t, syslog, cron, and most Linux utilities) or milliseconds (used by JavaScript's Date.now(), Java's System.currentTimeMillis(), and most chat and social-media APIs). You will occasionally see microseconds (PostgreSQL's epoch extraction, Python's time.time_ns() // 1000) and nanoseconds (Go's time.Now().UnixNano(), kernel tracing). This converter auto-detects seconds vs milliseconds at the 1e11 boundary, which cleanly separates every realistic value.
Unix time deliberately excludes leap seconds. Every Unix day is exactly 86,400 seconds long, even on the rare days when UTC inserts a leap second to keep wall-clock time aligned with Earth's rotation. Different operating systems handle this differently: Linux historically repeats the second 23:59:59, while Google, AWS, and Facebook smear the leap second across a 24-hour window. For application code this is invisible; high-precision scientific work uses TAI or GPS time instead.
The famous Year 2038 problem is when Unix time exceeds 2,147,483,647 seconds (03:14:07 UTC on 19 January 2038) and overflows a signed 32-bit integer. Systems using time_t as a 32-bit signed integer will wrap to negative and jump back to 1901. The fix — already deployed in modern Linux, macOS, all 64-bit platforms, JavaScript, Python, and Go — is to use 64-bit time, which pushes the overflow past the heat death of the sun. The remaining risk is in embedded systems, legacy file formats, and old database schemas that still store time as INT rather than BIGINT.
When you need a human-readable rendering, the two standards you will see are ISO 8601 (e.g. 2025-11-27T00:00:00Z — used by JSON APIs, HTML datetime attributes, and most modern protocols) and RFC 2822 (e.g. Thu, 27 Nov 2025 00:00:00 GMT — required by HTTP Date headers and email envelopes). Both describe the same absolute instant; ISO 8601 is more compact and lexicographically sortable, while RFC 2822 is more human-friendly inside protocol headers.
Discord introduced dynamic timestamps in 2021 — markdown of the form <t:1764201600:F> that the client renders in each viewer's local timezone. The format codes (t, T, d, D, f, F, R) control short/long date/time and relative phrasing. They've become the de-facto way to coordinate event times across timezones in gaming, OSS, and developer communities, and this converter outputs them directly so you can paste a timestamp into any Discord message.
Code samples
Copy-paste recipes for converting between epoch and human-readable formats in the languages you're most likely to be debugging.
// Now → epoch seconds
const epoch = Math.floor(Date.now() / 1000);
// Epoch → Date
const date = new Date(epoch * 1000);
// Epoch → ISO 8601
console.log(new Date(epoch * 1000).toISOString());
// "2025-11-27T00:00:00.000Z"import time
from datetime import datetime, timezone
# Now → epoch seconds
epoch = int(time.time())
# Epoch → datetime (UTC)
dt = datetime.fromtimestamp(epoch, tz=timezone.utc)
# Epoch → ISO 8601
print(dt.isoformat())
# "2025-11-27T00:00:00+00:00"package main
import (
"fmt"
"time"
)
func main() {
// Now → epoch seconds
epoch := time.Now().Unix()
// Epoch → time.Time
t := time.Unix(epoch, 0).UTC()
// Epoch → ISO 8601 (RFC 3339)
fmt.Println(t.Format(time.RFC3339))
}-- Now → epoch seconds
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;
-- Epoch → timestamp (UTC)
SELECT TO_TIMESTAMP(1764201600) AT TIME ZONE 'UTC';
-- Timestamp → epoch
SELECT EXTRACT(EPOCH FROM '2025-11-27 00:00:00+00'::TIMESTAMPTZ)::BIGINT;# Now → epoch seconds
date +%s
# Epoch → human-readable (GNU date)
date -d @1764201600 -u
# Thu Nov 27 00:00:00 UTC 2025
# Epoch → ISO 8601 (BSD/macOS date)
date -r 1764201600 -u +"%Y-%m-%dT%H:%M:%SZ"Related tools
Other developer-friendly time tools
Questions
Frequently asked questions
- What is a Unix timestamp?
- A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on Thursday, 1 January 1970 — the Unix epoch. Leap seconds are deliberately ignored, so the count is monotonically tied to UTC's elapsed seconds. The format is timezone-agnostic by design: a single integer represents an absolute instant, and the same value means the same moment everywhere on Earth.
- Is the timestamp in seconds or milliseconds?
- It depends on the producer. POSIX, most Linux tools, syslog, and cron use seconds. JavaScript's Date.now(), most JSON APIs, and Java's System.currentTimeMillis() use milliseconds. (Discord snowflake IDs are different again: they embed a millisecond count from 1 January 2015, not 1970.) This converter auto-detects: any value greater than 100,000,000,000 (1e11) is treated as milliseconds, otherwise as seconds. That threshold lands between 1973 (in ms) and the year 5138 (in seconds), so every realistic timestamp resolves correctly.
- What is the Year 2038 problem?
- On 19 January 2038 at 03:14:07 UTC, the Unix timestamp will exceed 2,147,483,647 — the maximum signed 32-bit integer. Systems that store time in a signed 32-bit field will overflow and wrap to a negative number, jumping back to 1901. Fixing it means using a 64-bit signed integer (which delays the overflow by 292 billion years). Most modern OSes and languages already use 64-bit time_t, but embedded systems, old databases, and legacy file formats remain at risk.
- Does Unix time include leap seconds?
- No. Unix time is defined as elapsed non-leap seconds since the epoch — every Unix day is exactly 86,400 seconds long. When a leap second is inserted into UTC (most recently in 2016), Unix time either smears it across the day (Google, AWS) or repeats the second 23:59:59 (Linux). For most application code this is invisible, but high-precision scientific code uses TAI or GPS time instead.
- What's the difference between ISO 8601 and RFC 2822?
- ISO 8601 is the modern international standard — "2025-11-27T00:00:00Z" — used by JSON APIs, log files, and HTML datetime attributes. RFC 2822 is the older format — "Thu, 27 Nov 2025 00:00:00 GMT" — required by HTTP Date headers and email envelopes. Both describe the same instant; ISO 8601 is more compact and machine-friendly while RFC 2822 is more human-friendly for headers.