Verificador de portabilidade de strings de data
Cole uma data ou timestamp (ou um trecho completo de log) e veja quais valores seriam interpretados de forma diferente — ou rejeitados — por JS Date, Python e outros analisadores comuns, e por quê.
O processamento é feito localmente no seu navegador. Seu arquivo nunca é enviado.
Como usar esta ferramenta ferramenta
- Cole uma data ou um bloco de texto maior com datas; os dados não saem do navegador.
- Selecione ‘Analisar datas’.
- Confira cada valor sinalizado: o que o torna ambíguo ou arriscado e quais ambientes divergem.
- Use a conversão sugerida para ISO 8601 quando disponível. Algumas ambiguidades não podem ser resolvidas automaticamente; são explicadas em vez de adivinhadas.
Premissas
- Reconhece cinco formatos específicos de data/hora: datetime ISO 8601 completo (com ou sem deslocamento), data simples YYYY-MM-DD (com ou sem zeros à esquerda), data com hífens e ano de dois dígitos e data separada por barras. Datas em linguagem natural (‘March 3rd’), timestamps Unix e outros formatos locais estão fora do escopo.
- A ordem dia/mês de uma data com barras só é inferida quando os números a determinam (um componente é maior que 12). Se ambos puderem ser meses, a ferramenta informa a ambiguidade em vez de escolher silenciosamente.
- O século de um ano com dois dígitos nunca é inferido, mesmo quando existem convenções comuns, porque elas realmente variam entre ambientes e bibliotecas.
Fontes e dados de referência
Metodologia
Cada substring parecida com data é classificada pelo formato e comparada com divergências conhecidas entre JS Date, Python e analisadores estritos (incluindo alguns mecanismos SQL): meia-noite UTC implícita versus local em datas sem horário; interpretação local versus UTC em datetime sem deslocamento; inferência de século para anos de dois dígitos; e rejeição de componentes sem zeros à esquerda por analisadores estritos. Só se sugere uma conversão para ISO 8601 inequívoca; nunca se adivinha.
Exemplo resolvido
Data ambígua separada por barras
Dados de entrada: 01/02/2024
Resultado: Tanto 1 quanto 2 são meses válidos; dependendo da convenção, pode significar 2 de janeiro ou 1º de fevereiro. É sinalizada como erro e não há conversão automática: adivinhar a ordem pretendida seria pior do que deixar o problema visível.
String ISO contendo somente uma data
Dados de entrada: 2024-01-15
Resultado: `new Date("2024-01-15")` do JavaScript interpreta como meia-noite UTC, enquanto outras linguagens e a forma `new Date(year, month, day)` do JavaScript interpretam uma data simples como meia-noite local. Em um fuso a oeste de UTC, isso pode corresponder a outro dia do calendário. A ferramenta avisa sobre o risco; a string já é ISO 8601 válida e não é reescrita.
Data sem zeros à esquerda
Dados de entrada: 2024-1-5
Resultado: JavaScript e Python aceitam esse formato de maneira permissiva, mas alguns analisadores estritos de datas SQL o rejeitam. Reescrita segura para 2024-01-05.
Orientações práticas
- Inclua sempre um deslocamento UTC explícito (ou ‘Z’) em qualquer timestamp com horário que atravesse a fronteira entre sistemas; é a forma confiável de remover ambiguidades.
- Nunca gere anos com dois dígitos no código que você controla: as regras de inferência de século variam entre ambientes e, depois que o ano é truncado, não há como corrigi-lo na leitura.
- Prefira ISO 8601 (‘YYYY-MM-DD’ ou datetime completo com deslocamento) para datas lidas por mais de um sistema, inclusive outra versão do seu próprio código.
Erros comuns
- Tratar ‘a data foi analisada sem erro’ como prova de que foi interpretada corretamente: todos os casos ambíguos verificados podem ser analisados com sucesso em todos os ambientes e produzir valores diferentes.
- Presumir que uma string simples ‘YYYY-MM-DD’ é segura em relação a fusos porque parece ISO 8601. O formato é inequívoco como texto, mas seu significado como instante depende de como o analisador preenche o horário ausente.
Perguntas frequentes
Por que 01/02/2024 é sinalizado como erro, mas 25/12/2024 é apenas informativo?
Em 01/02/2024, tanto 1 quanto 2 são números de mês válidos, então a ordem não pode ser determinada apenas pela string. Em 25/12/2024, 25 não pode ser mês, portanto a ordem dia/mês fica definida. Ainda não é ISO 8601, mas não é ambígua: recebe gravidade menor e pode ser reescrita automaticamente.
Por que a ferramenta não presume que um ano de dois dígitos como ‘24’ significa 2024?
É provável, mas alguns sistemas interpretam a mesma string como 1924 e outros como 2024 conforme a convenção de século implementada. A ferramenta não adivinha silenciosamente quando uma suposição incorreta seria pior do que não fazer suposição.
Uma data simples como 2024-01-15 é realmente insegura?
O risco diz respeito ao instante que ela representa quando lida por JS Date em comparação com a maioria dos outros analisadores: JavaScript trata uma data sem horário como UTC, enquanto muitas outras linguagens a tratam como horário local. Como texto ou dado armazenado, ela é segura; o risco surge quando é convertida em objeto de data e se pergunta qual instante representa.
Por que `new Date('2024-01-15')` pode mostrar o dia anterior?
ECMAScript interpreta a forma ISO somente com data como meia-noite UTC. Em um fuso a oeste de UTC, exibir esse instante no horário local pode resultar no dia anterior do calendário. Isso difere de construir meia-noite local ou tratar o valor como data sem fuso; o verificador explica o risco pelo formato, mas não executa analisadores de outros ambientes.
Última revisão:
Detector limitado baseado em formatos, não analisador completo de datas: reconhece cinco padrões específicos e nada mais. Não detecta datas em linguagem natural, timestamps Unix nem formatos locais incomuns. Também não pode saber qual data era pretendida em um caso realmente ambíguo; informa a ambiguidade em vez de resolvê-la.
As preferências de tema e de ferramentas, além das listas de itens salvos e usados recentemente, são armazenadas somente neste navegador.