⏰ Timestamp Converter
Convert Unix timestamps to human-readable dates and back — seconds, milliseconds, microseconds and nanoseconds are detected automatically. See the instant in any timezone, ISO 8601, RFC 2822 or relative form, and shift it by days, hours or minutes. Everything runs in your browser.
Convert a timestamp now ↓⏰ Unix timestamp converter
📅 Date → timestamp
Naive dates (no timezone in the text) are interpreted as your local time (detected as local); a trailing Z or +02:00 is honoured when present.
➕ Date arithmetic
🌍 The same instant around the world
| Timezone | Local time | Offset |
|---|
Rendered with your browser's Intl.DateTimeFormat database — summertime transitions are applied correctly, and no request leaves the page.
🕰️ What is Unix time?
Unix time (also called epoch time, POSIX time or a Unix timestamp) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 — a moment known as the epoch. It is the least ambiguous way to record an instant: no timezone, no daylight-saving rules, no month names, no locale. That is why logs, databases, JWT exp claims, HTTP caching headers, API payloads and cron schedules all speak in epoch seconds.
The trade-off is readability. Nothing about 1758213000 tells a human whether it happened last week or during the Bronze Age, which is why a timestamp converter ends up in every developer's bookmarks. Paste the number, get the date back.
Unix time ignores leap seconds: every day is treated as exactly 86,400 seconds. That is a deliberate simplification so that time_t + 86400 is always "the same clock time tomorrow".
🔢 Seconds, milliseconds, microseconds or nanoseconds?
The single most common timestamp mistake is reading a millisecond value as seconds (or the reverse), which lands you tens of thousands of years off. Digit count is the reliable signal:
| Digits | Unit | Example value | Means |
|---|---|---|---|
| 10 | seconds | 1758213000 | 2025-09-18T16:30:00Z |
| 13 | milliseconds | 1758213000123 | same instant, ms precision (JavaScript Date.now()) |
| 16 | microseconds | 1758213000123456 | same instant, µs precision (PostgreSQL, Python) |
| 19 | nanoseconds | 1758213000123456789 | same instant, ns precision (Go, Java Instant) |
This converter counts the digits for you, states which unit it used, and lets you force a unit when a value is ambiguous (for example a 13-digit number that really is seconds, far in the future).
🚀 How to use this converter
- Timestamp → date: paste the number and press Convert (or Enter). You get the value in seconds, milliseconds, microseconds and nanoseconds, plus ISO 8601, RFC 2822, UTC, your local time and the timezone you picked from the dropdown.
- Date → timestamp: type almost any shape of date —
2026-09-18,2026-09-18 20:30,2026-09-18T20:30:00Z,2026-09-18T20:30:00+08:00— or pick one with the date/time control, and read the epoch value back. - Shift a date: choose an amount and a unit (seconds through weeks) and apply it to the converted time. Handy for expiry dates: "this token lives 7 days, so it dies at…".
- Compare zones: the table at the bottom shows the same instant across seventeen common IANA zones with their UTC offsets, so you can answer "what time is that for the customer in Sydney?".
Every column has its own copy button, and nothing you paste is transmitted — the page works with the network disconnected.
🌍 Timestamps and timezones
A Unix timestamp has no timezone: it is a point on a universal timeline, and the timezone is only applied when you render it. That leads to a familiar class of bug — a log says 2026-09-18T16:30:00Z, you read it as "16:30 my time", and every offset in your debugging story is wrong by the difference between your zone and UTC.
Two rules keep you out of trouble:
- Store instants as UTC (epoch seconds, or an ISO 8601 string ending in
Z). Store the user's timezone separately if you need to display wall-clock times. - Never store "local" times as timestamps. A wall-clock appointment (a meeting at 09:00) and an instant (a log line) are different data types, even though both can look like a date.
This converter uses the ICU timezone database shipped with your browser through Intl.DateTimeFormat, so daylight-saving transitions (including the odd ones: Lord Howe Island's 30-minute shift, southern-hemisphere summer time) are handled by the same code that renders dates everywhere else on your machine.
⚠️ The year 2038 problem
On 2038-01-19T03:14:08Z a signed 32-bit Unix timestamp overflows — the moment is 2147483647 seconds. Systems that still store time_t as 32 bits (old embedded firmware, some databases and file formats) will wrap around to 1901. 64-bit epochs push that limit to roughly the year 292 billion.
JavaScript is not affected by 32-bit epochs — numbers are doubles, so the practical wall is the Date range of ±8,640,000,000,000,000 ms (about ±275,760 years) — but a converter is exactly where you want to check "what will this look like on the other side?". Paste 2147483648 and see.
💼 Use cases
- Debugging API responses: turn
created_at: 1758213000into something you can compare against your own clock. - JWT debugging:
expandiatare epoch seconds — check whether a token is actually expired, or expiring sooner than the logs suggest. Pair this page with the JWT Debugger. - Database work: PostgreSQL
extract(epoch from now()), MySQLUNIX_TIMESTAMP(), MongoDB ObjectId timestamps and SQLite's integer dates all speak the same language. - Cache and cookie debugging:
Expiresheaders are HTTP-dates, but signed URL and CDN TTLs are usually epoch values. - Log correlation: line up a client-side console timestamp with a server timestamp without doing offset arithmetic by hand.
- Data pipelines: spot a column that is "seconds since epoch" but arriving in milliseconds from one producer — a classic incident with a 1000× error.
❓ Frequently asked questions
How do I know if a timestamp is in seconds or milliseconds?
Count the digits: 10 = seconds, 13 = milliseconds, 16 = microseconds, 19 = nanoseconds. This converter detects the unit from the digit count and tells you which one it used, so you can spot a millisecond value that was about to be read as seconds.
Is the Unix epoch always 1970-01-01?
Unix time starts at 1970-01-01T00:00:00Z, and negative values are valid (-86400 is 1969-12-31T00:00:00Z). Other systems use different epochs: Windows FILETIME starts in 1601, NTP in 1900, .NET ticks in year 1, and GPS time in 1980 — a value that looks wrong by decades is usually a different epoch, not a broken timestamp.
Why does my timestamp show a different date than expected?
A Unix timestamp is always UTC. If you are off by a fixed number of hours, you are comparing a UTC rendering with a local-time rendering — check the timezone rows, which show the offset that was applied.
What is the year 2038 problem?
Signed 32-bit Unix timestamps overflow on 2038-01-19T03:14:08Z. This converter uses JavaScript numbers, so it renders dates far beyond that — paste 2147483648 to see the exact instant where 32-bit systems wrap.
Is my data sent anywhere?
No. Parsing, formatting, the timezone table and the arithmetic all run in your browser. The page contains no upload call, and it keeps working if you disconnect the network after loading.