ISO 8601 Converter

ISO 8601 is not a single format but a family of related representations, and the variant you almost certainly want for API work is the extended datetime format with a UTC offset: 2026-05-09T18:00:00Z. This is also the form mandated by RFC 3339, the stricter internet profile that JSON APIs, HTTP-based services, and OpenAPI specifications actually mean when they say "ISO 8601 date" — it requires a timezone designator, allows only the hyphenated extended layout, and prohibits week and ordinal dates. The basic format, 20260509T180000Z, omits every separator; it is rare in APIs but survives in calendar standards such as iCalendar and vCard and in some legacy EDI systems. The week date, 2026-W19-6, and the ordinal date, 2026-129, are more specialized still: they fit systems whose natural unit of time is a calendar week or a day of year, such as logistics planning, broadcast scheduling, and some financial reporting contexts.

For maximum compatibility across databases (PostgreSQL, MySQL, SQLite), languages, and cloud services, store timestamps as Unix integers in seconds and format them as extended ISO 8601 only at the API boundary. The split decouples storage from presentation: the integer sorts correctly, compares cheaply, and survives every driver and serialization layer, while the string stays readable in payloads, logs, and debugging sessions. Parsing in the other direction is where most production bugs live. A datetime string without an offset is interpreted differently across runtimes — JavaScript reads 2026-05-09 as UTC midnight but 2026-05-09T00:00:00 as local time — so attach Z or an explicit offset before any string crosses a process boundary. This converter always attaches an explicit offset for that reason. Remember that Z and +00:00 denote the same instant yet fail a string comparison, and that fractional-second precision varies between milliseconds and microseconds from one API to the next; the common pitfalls above walk through each of these failure modes.