Date and time
Enter one ISO or RFC date per line. Missing time zones stay unspecified unless you explicitly choose UTC.
Your input is processed in this browser and is not sent to a server.
One date per line: 2024-01-01T08:00:00+08:00, 2024-01-01, 08:00, or Sun, 06 Nov 1994 08:49:37 GMT.
Up to 9 fractional digits. Unix seconds/milliseconds round down; nanoseconds stay exact. HTTP output requires whole seconds.
1000 lines; 100000 UTF-16 code units total; 512 per line. Empty lines are errors.
Enter input or choose an example to begin.
Use this ISO 8601 converter to investigate a date copied from an API response, email header or server log. A clock reading and an instant are different: the offset tells you how to connect them.
A malformed calendar date is reported on its own line. Original fields remain beside the normalized result, so an unexpected day change can be traced to the offset instead of hidden by a permissive parser.
The ISO 8601 converter keeps 08:00 at +08:00 distinct from 00:00Z in its field report while giving both the same Unix value. This helps explain why a displayed date can change when an API normalizes to UTC.
A date alone does not include a clock time. A time alone lacks a calendar date. Neither becomes a timestamp here; even the explicit UTC option cannot fill those missing parts.
The ISO 8601 parser labels full RFC 3339 strings separately from compatible inputs with a space, omitted seconds or a compact offset. The ISO 8601 date formatter always shows the normalized form beside the original fields.
Leave missing zones unspecified for logs whose origin you do not know. Choose UTC only when that is what the source means. The report records the assumption, while explicit offsets always take precedence.
Automatic parsing waits 350 ms. Turn it off to use Parse or Ctrl/Cmd + Enter. Any edit disables export until results refresh; Show more adds 50 rows, while both exports include every input line.
Year, month and day are checked together, including leap years. Hours, minutes and seconds have fixed bounds. Invalid dates are rejected rather than rolled into the next month.
Read the declared RFC 2822/5322 subset, including numeric offsets and GMT or UT. A supplied weekday must match the date. Canonical IMF-fixdate is identified as HTTP; compatible mail forms remain labeled as mail.
The RFC 3339 converter keeps up to nine fractional digits. UTC uses nine digits; Unix nanoseconds remain an exact integer string. Seconds and milliseconds are floored, including instants before 1970.
The HTTP date converter emits IMF-fixdate only for whole seconds and UTC years 1900–9999. Fractions are never discarded to make a header: the exact ISO result remains available with an explanation.
Z marks a zero UTC offset. For example, 08:00+08:00 and 00:00Z on the same date identify the same instant. This does not identify the place where the clock reading originated.
ISO date-time uses numeric calendar fields; RFC mail dates use English month names and may include a weekday. This page converts the supported mail subset to ISO and UTC, and checks the weekday instead of silently ignoring it.
ISO includes representations without an offset. Those fields alone may not identify an instant. This tool preserves that distinction and only applies UTC to a complete unzoned date-time after you select that option.
Check the declared grammar first: week dates, zone annotations, decimal commas, leap seconds and overly long fractions are not supported. The error stays on its original line, so other valid lines can still be inspected.
No. September has 30 days, so 2025-09-31 is rejected. This tool validates the actual Gregorian calendar date rather than relying on a runtime that might normalize overflow to October.
Unexpected result?
Return to the ISO 8601 converter with the original value, then compare its fields, offset and precise UTC representation before using an exported report.