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.
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
Loading Timestamp Converter…
Loading Timestamp Converter…
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.
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.
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.
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.
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.
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.
Short answers for the things developers usually ask before trusting a tool.
No. Conversions use your browser's built-in Intl time-zone data; your input is not sent to a server.
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.
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.
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.
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.
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.
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.
Useful follow-ups when one conversion usually turns into three more.
Parse standard, Quartz.NET and Hangfire cron expressions into plain English and see the next 12 scheduled run times.
Generate UUID v1, v4, and v7 in bulk, or validate and inspect any UUID — with .NET Guid.ToString N, D, B, P and X formats.
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