Validador de Data ISO/Padrão

Variantes do formato ISO 8601: básico, estendido, ordinal e por semana

ISO 8601 não e um único formato — e uma família de representacoes para datas e horários. A forma famosa YYYY-MM-DD e so a ponta: o padrão também define a versão básica (sem separadores) e a estendida (com separadores), datas ordinais que contam o dia desde 1 de janeiro, datas por semana ancoradas na segunda-feira e date-time com fracoes de segundo e offset de fuso. Este validador foca nas variantes de formato: a forma textual exata que a string precisa ter para ser aceita por RFC 3339, W3CDTF, JSON Schema ou a futura Temporal API.

Uma checagem so de formato responde a uma pergunta: essa string esta sintaticamente correta? A validade semântica (existe 30 de fevereiro?) e uma checagem separada que envolve regras de ano bissexto e comprimento de mês.

Seis perfis que você vai encontrar

• RFC 3339 (timestamps de internet) — YYYY-MM-DDTHH:MM:SS+HH:MM. Subconjunto estrito de ISO 8601 usado por JSON, OAuth, cabeçalhos HTTP de data.
• W3CDTF (perfil web) — subconjunto ainda mais estreito do RFC 3339, adotado por Atom, RSS e sitemap.xml.
• Formato estendido com milissegundos — YYYY-MM-DDTHH:MM:SS.sss+HH:MM. Saída padrão de Date.prototype.toISOString().
• Formato básico (sem separadores) — YYYYMMDDTHHMMSS+HHMM. Usado em nomes de arquivo e EDI antigo.
• Data ordinal — YYYY-DDD, ex.: 2024-300 significa o dia 300 de 2024 (26 de outubro). Comum em aviacao e astronomia.
• Data por semana — YYYY-W##-D, ex.: 2024-W45-3 e a quarta-feira da semana ISO 45. Usado em varejo e folha de pagamento.

Um regex de validação hardcore

Um regex que cobre RFC 3339 e o formato estendido de uma vez:

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

Ele aceita 2024-03-15, 2024-03-15T10:30:00, 2024-03-15T10:30:00.123Z, 2024-03-15T10:30:00-03:00. Rejeita 2024/03/15, 15-03-2024 e zeros a esquerda faltando. Para ordinal e por semana, precisa adicionar alternativas: \d{4}-\d{3} e \d{4}-W\d{2}-\d.

Casos limite semanticos que o regex não pega

• 29 de fevereiro em ano bissexto — so vale se ano % 4 == 0 && (ano % 100 != 0 || ano % 400 == 0). Assim, 2000 sim, 1900 não, 2024 sim, 2100 não.
• Dias por mês — 31 em jan/mar/mai/jul/ago/out/dez, 30 em abr/jun/set/nov, 28-29 em fevereiro.
• Hora 0-23 — a revisão ISO 8601:2019 acabou com o caso especial 24:00:00 para meia-noite, que versões antigas permitiam.
• Segundo bissexto — 23:59:60Z no último dia de junho ou dezembro e um leap second legal pelo IERS, mas a maioria dos parsers rejeita.
• Timezone Z — equivale a +00:00 (UTC).

Um validador realmente estrito combina regex (formato) com lógica de calendário (semântica). Apps brasileiros ganham uma simplificacao: BRT e -03:00 o ano inteiro porque o Brasil aboliu o horário de verão em 2019.

Bibliotecas estritas vs o Date permissivo

O new Date(str) do JavaScript e propositalmente flexivel: chama Date.parse(), que aceita várias strings não-ISO ("March 15 2024", "2024/03/15") com comportamento dependente de implementação. Para entrada não confiável, use um parser estrito:

• Day.js — dayjs(str, 'YYYY-MM-DDTHH:mm:ss', true), o terceiro argumento liga o modo estrito.
• Luxon — DateTime.fromISO(str, { setZone: true }).isValid.
• date-fns — parseISO(str) + isValid() para um parse so ISO.
• Temporal API — Temporal.PlainDate.from(str) lanca em entrada invalida; embrulhe num try/catch.

Formatos de exibição vs formatos de armazenamento

ISO 8601 e a escolha certa para armazenar e transportar — ordenavel como texto, sem locale, legível por máquina. Para exibir a humanos, use formato de locale: DD/MM/YYYY no Brasil, MM/DD/YYYY nos EUA, YYYY/MM/DD no Japão. A regra e universal: guarde ISO, renderize com Intl.DateTimeFormat ou sua lib de i18n. Misturar as duas coisas e a origem da maioria dos bugs de data em produção.

FAQ

O separador T e obrigatório? No RFC 3339, sim — data e hora devem ser unidas pelo literal T (ou, por pedido dos humanos, um espaço). O ISO 8601 puro permite espaço; a maioria das APIs rejeita.

Z e válido? Sim — Z (Zulu) significa UTC e equivale a +00:00. RFC 3339 prefere por ser mais curto.

Data por semana e usada de verdade? Rara em APIs, mas padrão em varejo, folha de pagamento e calendarios ISO. 2024-W01-1 e a segunda-feira da primeira semana ISO de 2024 (que pode cair em dezembro de 2023).

Por que meu regex aceita 2024-02-30? Porque regex valida so formato. Validade de calendário precisa de função de calendário. Use uma biblioteca ou faca check por comprimento de mês.

ISO 8601 suporta datas antes de Cristo? Sim, com sinal opcional: -0001-01-01 e o ano 1 a.C. (calendário gregoriano proleptico). A maioria dos parsers não implementa.