ISO Date Converter

About the ISO 8601 Date Converter

Date and time formats are a graveyard of incompatible 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.

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.

Why does the relative time say 'in 2 days' for a date that's clearly only 47 hours away?

Relative time rounds to the nearest whole unit by default — 47 hours rounds to 2 days because the next larger unit (days) is closer than the current unit (hours) to a clean cutoff. The cutoff logic: under 60 seconds → 'just now' or 'X seconds'; under 1 hour → 'X minutes'; under 1 day → 'X hours'; under 30 days → 'X days'; under 1 year → 'X months'; otherwise 'X years'. This matches the Intl.RelativeTimeFormat conventions used by browsers, OS notifications and most messaging apps. For exact-precision arithmetic (e.g., 'how many minutes until my 3PM meeting'), use the epoch-second output and subtract.

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.