Date Format Validator (ISO/Common)

ISO 8601 format variants: from basic to extended, ordinal to week-based

ISO 8601 is not a single format but a family of representations for dates and times. The headline form YYYY-MM-DD is just the tip — the standard also defines basic (no separators) and extended (with separators) flavors, ordinal dates that count days from January 1, week-based dates anchored on Monday, and rich date-time strings with fractional seconds and timezone offsets. This validator focuses on the format variants: the exact textual shape the string must take to be acceptable to RFC 3339, W3CDTF, JSON Schema or the upcoming Temporal API.

A solid format-only check answers one question: is this string syntactically conformant? Semantic validity (does February 30 exist?) is a separate check covered by leap-year and month-length logic.

Six profiles you will encounter

• RFC 3339 (internet timestamps) — YYYY-MM-DDTHH:MM:SS+HH:MM. A strict subset of ISO 8601 used by JSON, OAuth, HTTP date headers.
• W3CDTF (web profile) — even narrower subset of RFC 3339 adopted by Atom, RSS, sitemap.xml.
• Extended format with milliseconds — YYYY-MM-DDTHH:MM:SS.sss+HH:MM. Default of Date.prototype.toISOString().
• Basic format (no separators) — YYYYMMDDTHHMMSS+HHMM. Used in filenames and legacy EDI.
• Ordinal date — YYYY-DDD, e.g. 2024-300 means day 300 of 2024 (October 26). Common in aviation and astronomy.
• Week-based date — YYYY-W##-D, e.g. 2024-W45-3 is Wednesday of ISO week 45. Used by retail/payroll systems.

A hardcore validation regex

A regex that matches the RFC 3339 / extended profiles in one shot:

/^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[+-]\d{2}:\d{2})?)?$/

It accepts 2024-03-15, 2024-03-15T10:30:00, 2024-03-15T10:30:00.123Z, 2024-03-15T10:30:00-03:00. It rejects 2024/03/15, 15-03-2024 and missing leading zeros. For ordinal and week-based, you need additional alternations: \d{4}-\d{3} and \d{4}-W\d{2}-\d.

Semantic edge cases the regex will not catch

• Leap year February 29 — only valid when year % 4 == 0 && (year % 100 != 0 || year % 400 == 0). So 2000 yes, 1900 no, 2024 yes, 2100 no.
• Days per month — 31 in Jan/Mar/May/Jul/Aug/Oct/Dec, 30 in Apr/Jun/Sep/Nov, 28-29 in Feb.
• Hour 0-23 — ISO 8601:2019 dropped the special 24:00:00 representation of midnight that older revisions allowed.
• Leap seconds — 23:59:60Z on the last day of June or December is a legal IERS leap second, but most parsers reject it.
• Timezone Z — equivalent to +00:00 (UTC).

A truly strict validator combines regex (format) with calendar logic (semantics). Brazilian apps benefit from a fixed assumption: BRT is -03:00 year-round because Brazil abolished daylight saving time in 2019.

Strict libraries vs the permissive Date constructor

The JavaScript new Date(str) is intentionally lax: it calls Date.parse() which accepts many non-ISO strings ("March 15 2024", "2024/03/15") with implementation-defined behavior. For untrusted input, use a strict parser:

• Day.js — dayjs(str, 'YYYY-MM-DDTHH:mm:ss', true), the third argument enables strict mode.
• Luxon — DateTime.fromISO(str, { setZone: true }).isValid.
• date-fns — parseISO(str) + isValid() for a strict ISO-only parse.
• Temporal API — Temporal.PlainDate.from(str) throws on malformed input, so wrap it in try/catch.

Display formats vs storage formats

ISO 8601 is the right choice for storage and transport — sortable as text, locale-free, machine-readable. For display to humans, use locale formatting: DD/MM/YYYY in Brazil, MM/DD/YYYY in the US, YYYY/MM/DD in Japan. The rule is universal: store ISO, render with Intl.DateTimeFormat or your i18n library. Mixing the two is the root of most date bugs in production.

FAQ

Is the T separator mandatory? In RFC 3339, yes — date and time must be joined by literal T (or, on humans' request, a single space). ISO 8601 itself allows the space; most APIs reject it.

Is Z valid? Yes — Z (Zulu) means UTC and is equivalent to +00:00. It is preferred by RFC 3339 for brevity.

Are week-based dates used in practice? Rare in APIs but standard in retail, payroll and ISO calendar systems. 2024-W01-1 is Monday of the first ISO week of 2024 (which may belong to late December 2023).

Why does my regex pass 2024-02-30? Because the regex only validates format. Calendar validity needs a calendar function. Use a library or write a per-month-length check.

Does ISO 8601 support BCE dates? Yes, with the optional sign: -0001-01-01 is year 1 BCE (in proleptic Gregorian). Most parsers do not support this.