⌘ Config & DevOps

Unix Timestamp Converter

Convert Unix timestamps in seconds, milliseconds, microseconds or nanoseconds, and .NET ticks, to dates in any time zone, and dates back to timestamps — including DST edge cases.

Updated

s / ms / µs / ns .NET ticks Any IANA time zone DST-aware

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.

.NET ticks and DateTimeKind

Ticks are converted with ticks = (nanoseconds since 1970 ÷ 100) + 621355968000000000, entirely in BigInt, so a value round-trips with no digit drift. For tick input you choose the Kind: Utc ticks are the instant itself; Local ticks are wall-clock time in the selected zone, resolved with the same DST logic as date input (ambiguous times take standard time, as ToUniversalTime does); Unspecified is shown as UTC with a warning. DateTime.ToBinary() values, which keep the Kind in the top two bits, are recognised and decoded.

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, .NET ticks) is guessed from the number of digits; an 18-digit value from 5×10¹⁷ is read as ticks, 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.

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.

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 — except 18-digit values from 5×10¹⁷ to 7.5×10¹⁷, which are read as .NET ticks (years 1585–2377). 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.

How do I convert .NET ticks to a date?

A tick is 100 nanoseconds since 0001-01-01T00:00:00, so ticks = Unix seconds × 10,000,000 + 621,355,968,000,000,000. Paste the ticks (or pick the .NET ticks unit) and set the DateTimeKind: Utc, Local or Unspecified. The Kind matters because DateTime.Ticks has no zone, so DateTime.Now.Ticks and DateTime.UtcNow.Ticks differ by your offset. The math is done with BigInt, because current tick values are beyond JavaScript's safe integer range.

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.

Want the background and worked examples? There's a longer write-up.

Read the Timestamp Converter guide

Related guides