O bug off-by-1000: quando uma data mostra janeiro 1970 ou o ano 56000

Todos os usuários ingressaram em 1 janeiro 1970 — a tela que revela o bug e o back-end que estava perfeitamente correto

Uma página de perfil mostrando todas as contas perto de janeiro 1970 é um forte sintoma de escala. O backend pode ter retornado segundos de época corretos enquanto o código frontend os passou diretamente para um construtor Date que interpreta milissegundos. A contagem dos dias atuais diminui então por um fator de mil no eixo do calendário.

Não corrija a exibição adicionando um ano constante ou substituindo a data. Capture o campo bruto, seu contrato API e a chamada exata do construtor. ToolAcre permite forçar ambas as unidades, para que um valor possa ser testado sem alterar os dados de produção. A leitura correspondente a outro evento conhecido identifica o provável erro de limite.

Os dois sintomas - segundos alimentados a um milissegundo API pousando em janeiro 1970, e milissegundos alimentados a segundos API pousando dezenas de milhares de anos antes

Segundos interpretados como milissegundos chegam perto da época porque um bilhão de milissegundos é apenas uma pequena fração de século. O erro inverso expande um valor de trilhão de milissegundos para um trilhão de segundos, muitas vezes fora dos limites normais de aplicação. Ambas as falhas preservam os dígitos enquanto alteram sua escala.

O artigo publicado de dez versus treze dígitos já explica a heurística visual contemporânea e seus limites. Em vez disso, este artigo centra-se no diagnóstico e na prevenção: seleção explícita de unidades, evidência de eventos independentes e uma conversão na interface onde a representação de um produtor encontra o contrato de um consumidor.

Como ambos os ramos são determinísticos, o sintoma pode ser reproduzido com um único acessório. Isso torna a incompatibilidade de unidade mais fácil de provar do que o desvio intermitente do relógio ou o comportamento de formatação de localidade.

Onde o limite geralmente está - JavaScript e Java em milissegundos, ferramentas Unix, Python e a maioria dos bancos de dados em segundos, e a carga útil JSON entre eles

Este repositório prova que JavaScript Date consome milissegundos e que ToolAcre multiplica segundos antes de construir um. Ele não estabelece os padrões de cada Java, Python, shell ou banco de dados API nomeado na pasta de trabalho. Esses contratos devem ser verificados onde são utilizados.

Um número JSON não contém metadados de unidade. Nomear um campo `created_at` transfere a ambigüidade entre os serviços; nomeá-lo `created_at_s` ou documentar uma string ISO torna o contrato revisável. O adaptador receptor deve converter uma vez em sua representação interna, em vez de espalhar multiplicações pelas visualizações.

Escreva a conversão ao lado da definição do limite, não dentro de um auxiliar de exibição reutilizável. O adaptador conhece o contrato do produtor; um formatador genérico deve receber um instante já normalizado.

O limite da unidade é específico de API; este repositório prova que JavaScript Data usa milissegundos

Um fixture fraco como `0` não pode detectar o bug porque zero segundos e zero milissegundos nomeiam a época. Pequenos valores fabricados também podem parecer datas 1970 plausíveis. Um mock que retorna a mesma escala esperada pelo seu consumidor nunca exerce um verdadeiro descompasso de integração.

Escolha um instante conhecido diferente de zero e torne as duas interpretações visivelmente diferentes. Afirme o resultado canônico ISO no limite, não apenas que existe um objeto Date. Inclui um caso de milissegundos e um caso de segundos; Os próprios testes de ToolAcre comparam 1,000,000 em cada unidade exatamente por esse motivo.

Bugs unitários sobrevivem sempre que os testes não conseguem distinguir as duas escalas

Considere `created_at: 1738578000`. Forçado em segundos, torna-se `2025-02-03T10:20:00.000Z`; forçado em milissegundos, torna-se `1970-01-21T02:56:18.000Z`. Um registro de implantação criado em fevereiro 2025 resolve a ambiguidade sem depender apenas da contagem de dígitos.

Mantenha o JSON bruto ao lado do evento conhecido enquanto conserta o adaptador. Se o campo fosse `1738578000000`, a interpretação em milissegundos identificaria o mesmo instante. Os dois valores nunca devem ser aceitos de forma intercambiável dentro de um esquema, mesmo que um conversor possa demonstrar sua equivalência após aplicar a escala correta.

A data de implantação conhecida é uma evidência independente. Sem isso, a escolha do resultado mais plausível pode codificar a expectativa de um investigador, em vez de estabelecer o que o produtor pretendia.

Exemplo resolvido: teste um valor criado_at em ambas as unidades explícitas

O reparo durável começa no limite: analise a unidade de origem documentada, converta exatamente uma vez e exponha um valor interno digitado ou claramente nomeado. Descrições de esquema, exemplos e clientes gerados devem preservar o sufixo ou formato de data e hora. Um revisor pode então identificar uma multiplicação extra antes do tempo de execução.

Adicione um acessório de regressão com a escala real e uma expectativa ISO fixa. Evite autodetecção no código da aplicação quando o produtor tiver contrato; heurísticas servem para investigar dados legados incertos. ToolAcre rotula sua escolha detectada com precisão para que a estimativa não possa ser mascarada como metadados garantidos.

O que isso não cobre: ​​erros de fuso horário, que alteram a data em horas e não em décadas

Um erro de fuso horário normalmente muda a exibição em horas e pode ultrapassar um dia corrido. Um erro de fator 1,000 muda décadas ou milênios. A mistura dos diagnósticos incentiva ajustes de compensação em torno de um valor cuja escala já está errada. Verifique a unidade antes de inspecionar a formatação local.

Da mesma forma, uma origem de época errada pode permanecer sem sentido tanto em segundos quanto em milissegundos. Se nenhuma das interpretações corresponder a qualquer evento conhecido, pare de alternar e investigue o produtor. Um conversor restringe hipóteses; isso não prova que todo número inteiro grande é tempo Unix.

Se o ano for plausível, mas a hora estiver constantemente deslocada, investigue a apresentação da zona. Manter essas escalas de sintomas separadas encurta o caminho desde a captura de tela até a causa raiz.

Conclusão: uma unidade errada é um século errado - e como a unidade declarada do conversor de carimbo de data / hora Unix permite testar ambas as leituras em um momento

Uma unidade errada não é um metadado cosmético – ela muda no instante. Trate as telas pesadas de 1970 e os anos implausivelmente distantes como sinais para inspecionar a costura produtor-consumidor. O valor, o contrato unitário e o evento conhecido formam uma prova tripartida mais forte do que uma data aparentemente razoável.

Use o conversor para comparar leituras explícitas e depois codifique a escala escolhida em nomes, tipos e testes. O objetivo não é ensinar o software a adivinhar de forma mais inteligente. É para remover a suposição do caminho que cria datas para os usuários.

Uma revisão de código pode então fazer uma pergunta precisa em cada limite: qual unidade entra e qual unidade sai? Isso é mais confiável do que reconhecer um determinado número de dígitos.