ISO-8601 strings pack a full date-time and timezone into a single token like 2026-06-06T14:30:00+01:00. This parser pulls that token apart so you can inspect every field individually — invaluable when debugging an API response, a log line, or a date that “looks right but isn’t”. Everything is computed locally in your browser.
How it works
The parser matches the string against a strict ISO-8601 regular expression that captures each component:
^(\d{4})-(\d{2})-(\d{2})(?:[T ](\d{2}):(\d{2})(?::(\d{2})(?:\.(\d+))?)?(Z|[+-]\d{2}:\d{2})?)?$Each captured group is then range-checked: the month must be 1–12, the day must be valid for that month and year (including the leap-year rule for February), the hour must be 0–23, and minutes and seconds 0–59. Once the fields pass validation, the tool also computes the absolute instant by handing the string to the Date API, giving you the UTC date-time and epoch seconds.
Full parse example
Parsing 2026-06-06T14:30:00.250+01:00 yields:
| Field | Value |
|---|---|
| Year | 2026 |
| Month | 06 |
| Day | 06 |
| Hour | 14 |
| Minute | 30 |
| Second | 00 |
| Fraction | 250 (milliseconds) |
| Offset | +01:00 |
| UTC equivalent | 2026-06-06T13:30:00.250Z |
| Epoch (seconds) | The Unix timestamp for this instant |
The same instant in UTC is 2026-06-06T13:30:00.250Z, because the +01:00 offset means local time is one hour ahead of UTC.
Variants the parser handles
ISO-8601 date-times come in several common forms. The parser accepts all of these:
| String | Notes |
|---|---|
2026-06-06 | Date only — no time or offset |
2026-06-06T14:30:00Z | With UTC designator Z |
2026-06-06T14:30:00+05:30 | With positive offset (India) |
2026-06-06T14:30:00-08:00 | With negative offset (US Pacific) |
2026-06-06T14:30:00.500Z | With fractional seconds |
2026-06-06 14:30:00Z | Space separator instead of T (common in SQL) |
It rejects strings that look like ISO-8601 but have invalid field values, such as month 13, day 31 in April, or hour 25.
Why timestamps without an offset are dangerous
A string like 2026-06-06T14:30:00 with no Z or offset is ambiguous — it could mean 14:30 in London, New York, Tokyo, or anywhere else. Different systems interpret it differently:
- JavaScript’s
Date.parse()treats it as local time in some implementations. - PostgreSQL and most databases treat an unzoned timestamp as being in the session timezone.
- Python’s
datetime.fromisoformat()treats it as timezone-naive.
The parser flags missing offsets explicitly so you can identify these ambiguous strings before they cause wrong calculations. If you encounter one in an API response, ask the provider to send UTC or include an explicit offset.
Tips and notes
- A trailing
Z(Zulu) is equivalent to an offset of+00:00. - If the offset is missing, treat the time as “local to some unknown clock” — pin it down before doing arithmetic.
- The wall-clock fields and the UTC instant differ by exactly the offset; comparing the two is a quick sanity check.
- Fractional seconds beyond milliseconds (nanoseconds, picoseconds) are rare but valid in ISO-8601; this parser captures and displays the raw fraction string.