ISO 8601 Datetime Builder + Parser
ISO 8601 has a reputation for being "obvious" — until you need to express "the last Friday of each month for the next quarter" or "duration of 2 years, 3 months, 4 days, 5 hours". This builder lets you assemble any compliant ISO 8601 string from controls (date, time, offset, fractional seconds, duration components, repeating interval syntax) and parses any string you paste, surfacing the exact spec section that defines the form and translating it to a human-friendly description.
How to use the ISO 8601 Datetime Builder + Parser
Pick a mode: Date + time assembles a calendar timestamp; Duration builds PnYnMnDTnHnMnS strings; Interval combines start + end (or start + duration) with optional repetition; Parse takes any ISO 8601 string and tells you what it is.
The output shows the canonical ISO 8601 string, a JSON Schema "format" value if applicable, and a Unix-timestamp equivalent. For durations, the calculator also resolves "this duration applied to today" so you can sanity-check.
About ISO 8601 Datetime Builder + Parser
ISO 8601 is the international standard for representing dates and times. Its core principle is most-significant first ordering — year, then month, then day — so strings sort lexicographically into chronological order. The most common forms are YYYY-MM-DD for dates, YYYY-MM-DDTHH:MM:SSZ for UTC timestamps, and YYYY-MM-DDTHH:MM:SS±HH:MM for offset-aware timestamps.
Less commonly known but spec-compliant: ordinal dates (2026-148 = day 148 of 2026), week dates (2026-W22-4 = Thursday of week 22), durations (P3Y6M4DT12H30M5S = 3 years, 6 months, 4 days, 12 hours, 30 minutes, 5 seconds), intervals (2026-05-28T00:00Z/P1D), and repeating intervals (R5/2026-05-28T00:00Z/PT1H = 5 hourly events starting at the given time).
RFC 3339 is a stricter subset of ISO 8601 used in protocols like HTTP and JSON — it requires the T separator, fully numeric values, and an explicit offset or Z. If you're generating timestamps for an API, defaulting to RFC 3339 form is the safe choice.
Common use cases
- API design — choosing a canonical timestamp format for request / response payloads.
- Cron / scheduling alternatives — ISO 8601 repeating intervals are a more readable way to express "every 6 hours starting Monday".
- Reading log files — quickly parsing an unfamiliar timestamp like
2026-148T14:30:45Z(ordinal date). - Database migrations — converting legacy date formats into a consistent ISO 8601 representation.
- Calendar / iCal generation — RFC 5545 builds on ISO 8601; getting durations and recurrence rules right matters.
Frequently asked questions
What is the difference between Z and +00:00?
Can a duration have negative components?
Why does my parser reject <code>2026-05-28 14:30</code> (with space instead of T)?
T. Many parsers accept space as a tolerance, but RFC 3339 only requires it as a fallback — generators should always emit T.