Is anything I enter sent to a server?
No. Conversions use your browser's built-in Intl time-zone data; your input is not sent to a server.
⌘ Config & DevOps
Unix Timestamp Converter
Convert Unix timestamps in seconds, milliseconds, microseconds or nanoseconds to dates in any time zone, and dates back to timestamps — including DST edge cases.
s / ms / µs / ns Any IANA time zone DST-aware Batch mode
Loading Timestamp Converter…
Loading Timestamp Converter…
What this page sends
- Your input: Processed in this tab and not sent to a server.
- Page load: Loading the page requests HTML, scripts and images from ByteKiln, fonts from Google Fonts, and sends Google Analytics page views, tool-usage events and catalog interactions (tool/category IDs, result status and whether a click followed search — never your input, output or search terms). Privacy & sharing
How the Unix Timestamp Converter Works
Unix time counts seconds since 1970-01-01T00:00:00 UTC, which sounds simple until a log line has 13 digits instead of 10, an API returns microseconds, or a bug report says "it happened at 1:30 on the night the clocks changed". This converter handles those cases explicitly. It detects the unit from the number of digits and tells you what it assumed, keeps microsecond and nanosecond precision by working in BigInt instead of floating point, and formats the instant as ISO 8601, RFC 3339 and RFC 2822, in UTC and in any IANA time zone your browser knows about. Converting the other way — a wall-clock date to a timestamp — is where most tools quietly guess. Here, a local time that falls in a daylight-saving gap is reported as non-existent, and one that happens twice when clocks go back returns both timestamps. Timestamps past 2038-01-19 are flagged for anyone targeting 32-bit time_t, there's a batch mode for log lines, and a set of one-liners shows how to get the current timestamp in eight languages.
Precision
Input is parsed as a decimal string into BigInt nanoseconds, so 1700000000123456789 keeps every digit. JavaScript dates only have millisecond precision, so the date parts come from the millisecond value and the fractional seconds are printed from the full-precision number.
Time zones
Offsets come from Intl.DateTimeFormat with an IANA time zone, which uses your browser's built-in time-zone database. The offset at a given instant is computed from the formatted wall-clock time, so historical changes and DST rules are applied as the browser knows them.
Local time to timestamp
For a wall-clock time, the converter tries the offsets in effect a day and a half either side, keeps every candidate whose round trip gives back the same wall-clock time, and reports zero candidates as a DST gap and two as a DST overlap. An input with its own Z or ±HH:MM offset is used as-is.
Formats
ISO 8601 and RFC 3339 use Z for UTC and ±HH:MM otherwise, with fractional seconds only when they are non-zero. RFC 2822 is the email and HTTP date form. ISO week numbers follow ISO 8601, where the week containing the first Thursday is week 1.
Limitations
- The unit (seconds, ms, µs, ns) is guessed from the number of digits; very small or very large values can be misread, so check the unit it reports.
- Time zones come from your browser's built-in database, so historical offsets and future DST rule changes are only as current as your browser.
- Unix time ignores leap seconds, as nearly every system does; the tool can't show 23:59:60.
- Dates beyond JavaScript's range (±275,760 years) and non-Gregorian calendars are not supported, and only ISO-style date input is accepted, not 01/02/2026.
FAQ
Short answers for the things developers usually ask before trusting a tool.
How does it know whether my timestamp is in seconds or milliseconds?
By the number of digits: up to 11 is seconds, 12–14 milliseconds, 15–17 microseconds and 18 or more nanoseconds. Current dates are 10 digits in seconds and 13 in milliseconds. The tool shows which unit it assumed, and you can override it.
What is the Year 2038 problem?
Systems that store Unix time as a signed 32-bit integer overflow after 2,147,483,647 seconds — 2038-01-19T03:14:07Z — and wrap to 1901. Most modern software uses 64-bit time, but older C code, embedded firmware, some file formats and database columns don't. The converter flags any timestamp past that point.
Why do some local times have two timestamps, and some none?
Daylight saving time. When clocks go back, an hour of local times happens twice, so 01:30 on that night in New York is ambiguous — both timestamps are shown. When clocks go forward, an hour is skipped, so 02:30 doesn't exist; the tool says so and shows where most libraries move it.
Does Unix time include leap seconds?
No. Unix time pretends every day has exactly 86,400 seconds, so leap seconds are not counted, and a time like 23:59:60 cannot be represented. The converter rejects second 60 for that reason.
Why won't it accept 01/02/2026?
It is January 2 in the US and 1 February in the UK and India. Choose the date order, or use the ISO format 2026-02-01, which is never ambiguous.
Can it convert negative timestamps or dates before 1970?
Yes. Negative timestamps count backwards from 1970-01-01T00:00:00Z. The limit is the JavaScript date range, about 273,790 years either side of 1970.
Related tools
Useful follow-ups when one conversion usually turns into three more.
test-debug
Cron Parser
Parse any cron expression into plain English and see the next 12 scheduled run times.
encoding-ids
UUID Generator
Generate UUID v1, v4, and v7 in bulk, or validate and inspect any UUID.
test-debug
.NET Format Tester
Test C# DateTime, DateTimeOffset and number format strings — standard and custom — in five cultures, with output verified against real .NET 8 and a table of common formats.
Want the background and worked examples? There's a longer write-up.
Read the Timestamp Converter guide