O que é data de escorpião e por que ela aparece no seu projeto
Você já encontrou registros que pareciam certos quando entraram no sistema, mas queiram meses depois durante uma auditoria ou migração? Isso é comum quando se lida com data de escorpião. O termo não é oficial em nenhuma norma técnica. É uma expressão que surg iu nos círculos de engenharia de dados brasileiros para descrever aquele dado de data que foi preenchido com valores arbitrários, defaults suspeitos ou datas extremas para contornar restrições de nullable no banco de dados. Em vez de deixar um campo como NULL, alguém optou por jogar 1970-01-01, 1900-01-01, 2100-01-01 ou até a data atual como placeholder. Isso salva a inserção no momento, mas gera ruído silencioso que só aparece quando alguém tenta gerar um relatório ou fazer uma junção mais complexa. Eu já vi isso em sistemas legados de varejo onde o campo `data_vencimento` recebia 01/01/1970 sempre que o cliente não informava prazo. O programa não quebrava. O relatório simplesmente ficava inútil.
Identificando data de escorpião na prática
A primeira coisa que eu faço ao entrar num projeto com esse problema é rodar uma query de profiling rápido. No SQL Server, por exemplo: SELECT MIN(data_campo), MAX(data_campo), COUNT(*) FILTER (WHERE data_campo IN ('1970-01-01', '1900-01-01', '2100-01-01')) FROM tabela;
No PostgreSQL, a sintaxe muda ligeiramente, mas a lógica é a mesma. O que importa é visualizar a distribuição completa, não apenas os outliers óbvios. Às vezes, a data de escorpião não está nos valores extremos. Pode ser uma data como 02/30/2023 que o banco aceitou por conversão implícita e virou 03/02/2023 sem ninguém perceber. Eu já perdi meia manhã caçando isso em uma ETL que transformava strings mal formatadas em timestamps. Um insight que pouca gente considera: data de escorpião muitas vezes vem disfarçada de dado válido em tabelas de histórico. Um campo que era text e foi migrado para date pode ter recebido valores como "N/A", "PENDENTE" ou "--". O banco converte silenciosamente para NULL ou a data mínima dependendo do driver. O resultado final depende da configuração de `DATESTYLE` no PostgreSQL ou do `DATEFORMAT` no Snowflake. Se você não Checar isso antes da migração, os dados chegam ruins e você ainda perde tempo debugando query que "funciona mas retorna errado".
Como tratar data de escorpião em um pipeline
A abordagem mais direta que eu uso depende do estágio em que o dado está entrando. Se ainda está na fonte, o ideal é corrigir na origem. Mas na prática, isso raramente acontece. A solução realista é criar uma camada de saneamento logo na ingestão. Eu monto uma regra de validação que separa os valores em três buckets: datas válidas, datas suspeitas e datas impossíveis. Para definir os limites, eu considero o contexto do negócio. Uma data de nascimento não pode ser posterior a hoje. Uma data de vencimento de contrato nunca foi 1970. Uma data de alta de ação pode ser qualquer coisa nos últimos 50 anos. O bucket "suspeito" é onde mora a data de escorpião de verdade — valores que são tecnicamente válidos, mas estatisticamente improváveis para aquele domínio.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No código, eu faço algo próximo disso usando Python com pandas: df['data_campo'] = pd.to_datetime(df['data_campo'], errors='coerce')
df['data_flag'] = ~df['data_campo'].between('1990-01-01', '2030-12-31')
Isso converte tudo o que não é data válida para NaT e marca como suspeito o que fica fora da janela aceitável. O parâmetro `errors='coerce'` é importante porque converte strings como "31/02/2023" em NaT em vez de travar o pipeline. Sem isso, você perde toda a execução por um registro malformatado. Para os valores que caem nos buckets problemáticos, eu tenho duas opções. A primeira é tentar inferir o valor correto a partir de outras colunas. Se `data_vencimento` está como 1970-01-01 mas `data_contrato` existe, posso usar uma regra de negócio como "vencimento = contrato + 90 dias". A segunda opção, quando a inferência não é possível, é substituir por NULL e documentar a substituição em uma log table. Eu nunca recomendo deixar o valor suspeito passar adiante só porque "o código não quebrou".
Pegadinhas que eu aprendi na marra
Aqui vão dois problemas reais que eu enfrentei e que raramente aparecem em tutoriais básicos. O primeiro é fuso horário. Quando você trabalha com data de escorpião em ambientes distribuídos, uma data que parece correta em São Paulo pode estar errada em Londres. Eu já vi um relatório onde 40% dos registros tinham a data deslocada por 12 horas porque o sistema legado gravava timestamp em UTC e a aplicação lia como se fosse horário local. A solução não foi converter tudo. Foi decidir um fuso único de referência e aplicar a conversão apenas nos campos que vinham de fontes externas. O resto permanecia como estava.
O segundo problema é mais sutil: data de escorpião que se reproduz. Quando você consome uma API que retorna datas inconsistentes e transforma esses dados em uma tabela intermediária, a próxima ETL herda a sujeira. Eu já passei semanas tentando limpar dados que eram cópia de uma cópia de uma cópia. A solução foi criar um selo de qualidade na camada de ingestão. Cada lote recebe um metadado com a porcentagem de campos válidos, suspeitos e nulos. Se o índice cair abaixo de 95%, o lote é rejeitado automaticamente e o time responsável pela fonte é notificado. Isso evita que a data de escorpião se espalhe por múltiplas camadas do pipeline.
Alternativas quando a correção não é viável
Nem sempre dá para corrigir tudo. Em bancos com bilhões de linhas, uma atualização massiva pode derrubar a produção. Nesses casos, eu prefiro criar uma visão de saneamento que aplica as regras de limpeza em tempo de consulta. O custo é performance, mas pelo menos os dados que chegam ao usuário final estão tratáveis. Uma terceira alternativa é aceitar que parte dos dados será sempre imperfeita e documentar explicitamente quais campos têm taxa de completude conhecida. relatórios de gestão precisam saber disso. Um número com 60% de preen chi mento é melhor do que um número com 60% de preenchimento disfarçado de 100%. O problema maior com data de escorpião não é técnico. É político. Alguém no passado fez aquela escolha achando que estava resolvendo um problema. Agora você herda a consequência. O trabalho dele não é julgar essa decisão, mas garantir que o dado que sai do seu pipeline seja honesto sobre o que sabe e sobre o que não sabe.
