JavaScript Interpreta Quase Tudo como Data

O construtor new Date(string) não é só permissivo: ele é um parser heurístico que tenta extrair datas de qualquer texto, mesmo sem padrão. Isso vem de uma decisão antiga do ECMAScript, antes do ES5, cada engine (V8, SpiderMonkey) fazia isso à sua maneira; depois, a especificação permitiu 'algoritmos específicos da implementação' para strings fora do ISO 8601. O resultado? 'Route 66' vira 1966-01-01 e '90210' vira o ano 90210, não por falha, mas por design. Essa lógica não gera apenas dados errados, mas dados 'válidos' (sem Invalid Date), o que dificulta detecção em testes e produção.

O maior risco prático está no fuso horário: strings como '2024-03-15' ainda são interpretadas como UTC em muitos ambientes, embora a especificação do ES6 diga que devem ser locais. A inconsistência persiste porque navegadores e runtimes não sincronizaram totalmente a implementação. Para evitar surpresas, use sempre formatos explícitos, como '2024-03-15T00:00:00Z' para UTC ou '2024-03-15T00:00:00' + offset, e nunca confie na inferência automática.

Esse comportamento afeta diretamente qualidade de software, segurança e experiência do desenvolvedor (DX). Dados de formulários, APIs externas ou logs com strings não estruturadas podem ser convertidos em datas absurdas sem erro visível, gerando bugs silenciosos em relatórios, cálculos de prazos ou auditorias. Em sistemas financeiros ou de saúde, onde precisão temporal é crítica, um dia de desvio pode ter impacto legal. Além disso, o uso de bibliotecas como date-fns ou Day.js não é luxo: é defesa técnica contra uma API nativa que prioriza compatibilidade histórica sobre previsibilidade, algo que a nova API Temporal busca corrigir de forma estruturada.