ISO 8601 and RFC 3339 validator

How to use

1. Paste or type the text in Date or date-time. The buttons under the box fill in instructive examples.
2. Read the status line. It says what the text was read as: a date in calendar, ordinal or week form, or a date-time, in basic format (no hyphens and colons) or extended format.
3. Read the two verdict cards. ISO 8601 says whether the notation is valid in the standard, with the date checked against the real calendar. RFC 3339 says whether it is also a valid Internet timestamp. A red card lists the reasons, and notes are shown when something is valid but worth knowing.
4. Under What it means, a date is also shown in the other date forms (calendar, ordinal, week) with its weekday; a date-time with an offset also shows the UTC instant and its Unix seconds. Hour 24 is read as 00:00 of the next day.
5. The last block shows what Date.parse in your browser does with the same text. It is an observation about your browser, not a verdict.

Worked examples

Every verdict printed here is recomputed by an automated test from the same engine as the tool. The calendar and week arithmetic behind them is checked against Python's datetime on thousands of random dates.

The profile everyone means

02:30 at -05:00 is 07:30 UTC. (It is a real clock time in New York only before the clocks change on 8 March 2026; 02:30 on that date does not exist there, but the offset in the text is what the string says, so the string is valid and names an instant.)

Basic format, and the other date forms

All three of 2026-03-08, 2026-W10-7 and 2026-067 name the same day, a Sunday. A week-numbering year can have 52 or 53 weeks: 2026 has 53, 2025 has only 52 (see "What goes wrong").

Hour 24

Leap seconds

A Unix timestamp does not count leap seconds, so the leap second and the next midnight share one number. The same second written in another offset is recognised too:

Lower case

What goes wrong

Strings that look right and are not, or look wrong and are accepted. Each result is the tool's exact output.

Where the two verdicts disagree

The missing offset is the most common bug: 2026-03-08T02:30:00 is a perfectly good ISO 8601 local time, but it is not an instant, and two servers in different zones will read it as different instants.

Dates that do not exist

Not ISO 8601 at all

A leap second that did not happen

The string is well-formed and RFC 3339 does allow second 60 at the end of June, so both cards are green. The note is what tells you that 30 June 2026 had no leap second.

"It parsed in my browser, so it is valid"

JavaScript's Date.parse is only required to accept one format. Anything else is up to the engine, so a string that one browser accepts can give NaN in another. The last block of the tool shows your browser's answer. Use it as an observation, never as the validity test.

Limits & gotchas

• ISO 8601 was not read. The standard is sold by ISO, not published free. The ISO verdicts follow a published summary of the standard (Wikipedia) and the grammar in RFC 3339's Appendix A, which that RFC itself calls informational and possibly erroneous. Where the sources do not say (for example, whether a basic date can be mixed with an extended time), the page does not reject the string for it, it adds a note, and the RFC 3339 verdict, which is defined by a precise grammar, fails.
• Which ISO 8601 edition? The standard has changed between editions, notably for hour 24 (see the FAQ). The validator accepts 24:00 and says so; if you must follow a specific edition, check it.
• Reduced precision and expanded years are partly supported. The tool reads reduced-precision dates (such as 2026-03) and the signed six-digit expanded years that JavaScript uses. It does not handle time intervals (start/end) or repeating intervals, and it refuses them with that reason.
• Time zone designators. Only Z and numeric offsets are read. A bracketed zone name such as [Europe/Berlin] is not part of ISO 8601 or RFC 3339 and is refused.
• Leap-second check. The list was read on 2026-10-03; its last entry is the 2016-12-31 leap second and the list itself expires on 2027-06-28; a leap second announced later would not be known to this page until it is updated.
• The Date.parse block depends on your browser and is not a standard behaviour.

FAQ

Sources

• IETF (RFC Editor): RFC 3339: Date and Time on the Internet: Timestamps Used for: The date-time grammar (section 5.6) and its note that "T" and "Z" may be lower case and the T may be replaced by a space; hour 24 is not allowed; the leap second 60 is only valid at the end of a month, in practice June or December (5.7); -00:00 meaning an unknown local offset (4.3); Appendix A, a collected ABNF for ISO 8601 that the RFC itself calls informational and possibly erroneous.
• Wikipedia: ISO 8601 Used for: Calendar, ordinal and week dates; week 1 is the week with the year's first Thursday; the zero offset is written Z or +00:00 (not -00:00); 24:00 was allowed until the 2004 edition, removed in ISO 8601-1:2019 and reintroduced by Amendment 1 (2022); duration syntax PnYnMnDTnHnMnS, "P" alone is invalid, PT0S and P0D are valid, a fraction only on the smallest component, weeks as PnW, and that PT36H and P1DT12H are different durations across a DST change. ISO 8601 itself is sold, not free; it was not read.
• IANA: leap-seconds.list Used for: The 27 leap seconds inserted since 1972 (TAI minus UTC rose from 10 s to 37 s, last step at the end of 2016-12-31) and that the file carries an expiry time (2027-06-28), after which it must be re-read.
• Ecma International / TC39: ECMAScript Language Specification: Time Values and Time Range; Date.parse; time zone offset helper operations Used for: A time value is milliseconds since 1970-01-01T00:00:00Z with every day exactly 86,400,000 ms (leap seconds are ignored); the range is +-8.64e15 ms (+-100,000,000 days); for a local time that is skipped or repeated, the offset in use before the transition is applied; a skipped local time yields no instant in the time-zone-to-epoch operation.
• MDN Web Docs: Date Used for: The supported range (April 20, 271821 BC to September 13, 275760 AD, plus or minus 100,000,000 days); that Date ignores leap seconds; Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991; the date-time string format (a simplification of ISO 8601, 24:00:00 allowed, expanded years of + or - followed by six digits, -000000 disallowed); and that setting a local time inside a DST transition follows the Temporal "compatible" disambiguation: if the local time corresponds to two instants the earlier one is chosen, and if it does not exist the result goes forward by the gap duration (with the New York 2024 example).
• The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the Epoch Used for: Seconds since the Epoch "approximates" the seconds elapsed since the Epoch; the formula that relates a UTC date to it for years from 1970 and non-negative values; "If the year is <1970 or the value is negative, the relationship is undefined"; "each and every day shall be accounted for by exactly 86400 seconds" (so leap seconds are not counted); the relationship to actual UTC is unspecified.

Every document above was opened and read on 2026-10-03. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• ISO 8601 duration calculator

  Parse PnYnMnDTnHnMnS, see why months and years are not fixed lengths, and apply a duration to a date.

• Unix epoch converter

  Seconds, milliseconds, microseconds or nanoseconds to a date and back, with the unit guess explained and exact BigInt arithmetic.

• Time zone converter

  Convert a local time between IANA zones and see what happens when the time does not exist or happens twice.

• Year 2038 problem demo

  Watch a signed 32-bit seconds counter overflow, with the exact instants and what each reading means.