ISO Date Converter

About the ISO 8601 Date Converter

This timestamp converter tames a graveyard of incompatible date and time standards: ISO 8601 (with basic and extended forms), RFC 2822, RFC 3339, SQL DATETIME, Unix epoch in seconds / milliseconds / microseconds / nanoseconds, Excel serial dates, Julian Day Numbers, ISO week dates, ISO ordinal dates — and every system handles timezone offsets and leap seconds differently. This converter accepts almost anything (paste it, the tool auto-detects), then outputs every common form simultaneously, alongside four user-selectable timezones, the day of the year, ISO week number, calendar quarter, leap-year flag, and a human relative-time string ('3 hours ago', 'in 2 days').

No network calls, no cookies, no log — pure browser arithmetic against your machine's IANA timezone database. Perfect for log debugging, API contract testing, scheduling across teams, and exporting to spreadsheets. See also our Calendar Generator and Working Days Calculator.

What's the actual difference between ISO 8601 'basic' and 'extended' formats?

Extended format (the everyday one) uses separators: 2026-05-17T14:30:00.000Z. Basic format strips them: 20260517T143000Z. They contain identical information; the basic form was designed for systems with limited character sets (mainframes, barcodes, file-system names that disallow colons on Windows). Modern API ecosystems universally prefer extended for human-readability, but you'll still find basic in industrial logging, broadcast SMPTE timecode, and embedded device firmware. RFC 3339 (the HTTP-friendly profile of ISO 8601) explicitly forbids the basic form and requires the extended form with 'T' or ' ' as the time separator and 'Z' or '+HH:MM' as the timezone — that's why most REST APIs land on the format 2026-05-17T14:30:00Z.

How does the tool auto-detect whether my number is seconds, milliseconds, microseconds or nanoseconds?

By order of magnitude. Unix epoch in seconds is a 10-11 digit number for any date in our lifetime (1e9 ≈ 2001, 5e9 ≈ 2128). Milliseconds adds 3 zeros (1e12 ≈ 2001, 5e12 ≈ 2128 in ms). Microseconds adds another 3 (1e15-range). Nanoseconds adds another 3 (1e18-range). The parser checks: abs(n) < 1e11 → seconds; < 1e14 → ms; < 1e17 → µs; otherwise → ns. This is unambiguous for dates between roughly 1970 and 5000 AD. Edge cases: a literal '0' is treated as seconds (1970-01-01 UTC). A 13-digit number is always milliseconds. If you have an actual second-precision epoch in 2086 onward (>11 digits), prefix with a clarification — but that's not a 2026 problem.

How do I convert a Unix timestamp to a human-readable date (and back again)?

To go from epoch to date: paste the Unix timestamp into the main 'Date input' field. The tool auto-detects the unit by magnitude (seconds, milliseconds, microseconds or nanoseconds) and instantly renders the ISO 8601 extended form, RFC 3339, SQL DATETIME and the human-readable wall-clock time in all four timezone columns — so 1747490400 becomes 2025-05-17T14:00:00Z. To go the other way (date → epoch): paste any date or ISO 8601 string into the same field and read the 'Unix epoch (seconds)' and 'Unix epoch (milliseconds)' rows in the Epoch & serial table; each value is wrapped in a click-to-select code box for one-tap copying. Because seconds and milliseconds differ by a factor of 1000, always confirm which one your API or database column expects (PostgreSQL to_timestamp() and most languages' fromtimestamp() take seconds; JavaScript's Date and Java's Instant.ofEpochMilli() take milliseconds).

How do I calculate the exact time between two dates or timestamps?

Put the first instant in the main 'Date input' and the second in the 'Compare with' field (leave it empty to measure against the current moment). The Exact duration card then shows a signed, precise delta two ways: (1) a calendar breakdown in years, months, days, hours, minutes and seconds computed with real month lengths — not a 30-day approximation — so February and leap years are handled correctly; and (2) total values in days, hours, minutes, seconds and milliseconds, each in a copyable code box. This is exactly what you need for SLA breach windows, log-event gaps, uptime, billing periods, payroll spans and 'time until deadline' calculations, with no manual epoch subtraction. Both fields accept any format the tool understands (ISO 8601, Unix epoch, RFC 2822/3339, SQL DATETIME), so you can even compute the gap between an epoch-seconds value and a human-typed date.

Why does the relative time say '1 day' for a date that's clearly 47 hours away?

The relative-time string truncates (floors) to the largest whole unit — it never rounds up. 47 hours floors to '1 day', not 2, because we take Math.floor(47 / 24) = 1 and drop the remaining 23 hours. The cutoff logic: under 60 seconds → 'just now' or 'X seconds'; under 1 hour → floor to 'X minutes'; under 1 day → floor to 'X hours'; under 30 days → floor to 'X days'; under 1 year → floor to 'X months'; otherwise floor to 'X years'. This deliberate truncation matches how logs and CLI tools display age ('1d ago'), but it is lossy by design. For an exact, unambiguous answer, fill the 'Compare with' field (or leave it empty to compare against now): the Exact duration card shows the full calendar breakdown (e.g. '1 day 23h 00m 00s') plus copyable totals in days, hours, minutes, seconds and milliseconds — no manual subtraction required.

What is an ISO week date and when should I use it?

ISO week dates express a date as 'year-week-weekday' (e.g., 2026-W21-3 = Wednesday of week 21 of 2026). Two quirks: (1) ISO weeks start on Monday (not Sunday like the US convention); (2) week 1 contains the first Thursday of the year — meaning Jan 1-3 might belong to week 52 or 53 of the previous ISO year. Use ISO week dates for: payroll/timesheet systems (weekly rollups), retail planning (52 stable weeks per year), broadcast schedules, sprint planning that treats weeks as the atomic unit, and ICU charts that show 'days since admission' alongside 'week of stay'. Avoid for: human-readable communication ('book the meeting for week 21' is meaningless without a context calendar).

Are the four timezone columns synchronized to the same moment in time?

Yes — all four columns render the same UTC instant (whatever your input parses to), just expressed in different IANA timezones. If you enter 2026-05-17T12:00:00Z, you'll see 12:00 in the UTC column, 05:00 in Los Angeles (UTC-7 DST), 08:00 in New York (UTC-4 DST), and 19:00 in Ho Chi Minh (UTC+7). The browser's Intl.DateTimeFormat handles DST transitions, half-hour and 45-minute offsets (India is UTC+5:30, Nepal UTC+5:45), and historical timezone rule changes via the bundled IANA tzdata. Useful for cross-team scheduling, log correlation across regions, and verifying that your backend writes Z-suffixed UTC strings instead of accidentally serializing local time.

Why doesn't the Excel serial match what Excel shows on my computer?

Excel uses two date systems and most people don't realize. Default ('1900 date system'): day 1 = 1900-01-01, with a famous bug where Excel treats 1900 as a leap year (it wasn't) — adding a phantom day 60 = 1900-02-29 that never existed. Mac legacy ('1904 date system'): day 1 = 1904-01-01. This converter outputs against the Windows 1900 system (the default for new workbooks) but compensates for the leap-year bug by anchoring at 1899-12-30, which is the trick Excel itself uses internally to produce correct math for any date after 1900-03-01. If you're working in a Mac-1904 workbook, subtract 1462 from our serial value. To check which system your workbook uses: File → Options → Advanced → 'Use 1904 date system' checkbox.

What's the Julian Day Number for, and why is it a decimal?

Julian Day Number (JDN) is a continuous count of days since noon UTC on January 1, 4713 BCE (the proleptic Julian calendar epoch chosen by astronomers in 1583 because it predates all surviving historical records). The decimal portion is the fraction of the day past noon UTC: .0 = noon, .5 = midnight. JDN is dominant in astronomy, satellite orbital mechanics, and historical date arithmetic because it ignores calendar reforms (Julian → Gregorian in 1582, never adopted by some countries until the 20th century). Today's JDN is around 2,460,829. Modified Julian Day (MJD) is JDN − 2,400,000.5, shorter and used in space telemetry and CCSDS standards. If you're not in astronomy or aerospace, you probably don't need it — but spreadsheet wizards use it for clean date subtraction (delta days = JDN_b − JDN_a).

How does the tool handle leap seconds and dates before 1970?

Leap seconds: it doesn't. Both Unix epoch and JavaScript's Date object explicitly ignore leap seconds — every UTC day is exactly 86,400 seconds. Real UTC has had 27 leap seconds inserted since 1972, so technically there's a ~27-second offset between displayed UTC and 'true' atomic time. This matters for: GPS systems, financial market timestamps (post-MiFID II), high-precision scientific measurements. It doesn't matter for: logs, API timestamps, scheduling, anything human-facing. For dates before 1970, the tool happily handles them — negative epoch values, dates like 1066-10-14 (Battle of Hastings) and BCE dates work via JavaScript's Date, though the proleptic Gregorian calendar extension means the displayed date may not match the Julian calendar in effect at the time. For historical-precise calendar work, use a dedicated astronomy library.