Resposta direta
A escolha depende de quem lê o dado e de onde ele nasce. Se a data é usada só por pessoas e o volume é pequeno, aceitar o texto como está custa menos que criar regra de conversão. Se a data é cruzada com outros sistemas ou entra em cálculo, converter na leitura evita travar a operação, mas empurra a incerteza para quem interpreta o resultado. Exigir formato na entrada resolve daqui para frente e não corrige o que já está gravado. Corrigir o histórico em lote é possível, com erro provável nos casos ambíguos, como 03/04/05 e mês abreviado.
- Objetivo
- Comparar alternativas
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: As demais páginas do tema tratam divergência, duplicidade ou validação; esta compara opções para tratar um campo de data já gravado em texto livre e mostra o custo de cada uma.
O critério é o uso do dado, não o formato
A pergunta que ordena a decisão é simples: quem lê essa data e para quê. Se o campo só alimenta leitura humana, o custo de criar regra de conversão raramente se paga. Se a data alimenta cálculo, prazo, filtro ou cruzamento entre sistemas, o texto livre passa a ser risco de operação, não detalhe de cadastro.
O segundo critério é a origem. Data digitada por pessoa em campo aberto tem padrão diferente de data que chega de planilha, formulário ou importação. Misturar as duas origens numa mesma regra costuma gerar conversão que funciona para uma e falha na outra. Vale separar os campos por origem antes de decidir o tratamento.
Onde os formatos ambíguos aparecem
Textos como 03/04/05, abril/24, dia 3, março ou datas sem ano não têm leitura única. A regra escolhida para o conjunto decide por todas as linhas, inclusive as poucas em que está errada. Sem marca de origem ou de confiança no campo, o erro passa como se fosse dado correto.
Antes de converter, vale listar os formatos que aparecem de fato no campo e medir quantos registros ficam fora do padrão principal. Esse levantamento é o que separa conversão segura de conversão que inventa data. O que não se sabe deve ficar em separado, não preenchido por média.
O que qualquer padronização deixa em aberto
Nenhuma das opções corrige a causa: campo aberto continua aceitando texto livre até que alguém decida limitá-lo na entrada. Padronizar o existente melhora relatório e cruzamento, mas não impede que a próxima digitação venha fora de formato.
Também não se recupera o que foi interpretado errado no momento do registro. Se a pessoa digitou 03/04 querendo falar de abril e o sistema leu março, a data original se perdeu. Nesse caso a conversão apenas consolida o erro com aparência de organização. Para prazo contratual ou data fiscal, o caminho é conferir na fonte, não estimar.
Recurso prático
Quatro formas de tratar data em texto livre
| Alternativa | Serve quando | Limite |
|---|---|---|
| Aceitar o texto como está | A data é lida só por pessoas e o volume é pequeno | Impede cruzamento automático e cálculo confiável |
| Converter na leitura | A data entra em cálculo ou cruza com outros sistemas | A regra fica escondida em cada consulta e se repete |
| Exigir formato na entrada | O cadastro passa por formulário controlado | Não corrige o que já está gravado nem migrações antigas |
| Corrigir o histórico em lote | A base alimenta relatório e precisa de consistência | Erra nos casos ambíguos e não há volta fácil sem cópia |
O erro mais comum é padronizar só na entrada e supor que o passado ficou resolvido. A regra nova vale da data de implantação em diante, não para o que já está no banco.
Sobre o que está escrito aqui
Conceitos relacionados: campo de data em texto livre · normalização de formato · data ambígua · conversão na leitura · correção retroativa. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
- Validação na entrada: onde o dado errado nasce — dado errado na origem
Páginas relacionadas
O mesmo problema em outro objetivo
- Data em formato livre: como dizer se o campo é confiável — Diagnosticar
- Data em campo livre: como tornar o registro utilizável — Organizar um processo
- Data em formato livre: como medir o que dá para recuperar — Explicar medição
- Data em campo de texto: o que converter e o que anotar — Orientar implementação
- Campo de data em texto livre: o que exigir ao contratar — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Erro de sincronização achado pelo cliente: o que reconstruir — Roteiro de investigação para um erro de sincronização relatado pelo cliente: linha do tempo do dado, decisão tomada, causa e responsável.
- Registro excluído sem trilha: o que comparar antes de decidir — Compara as saídas para um registro excluído sem trilha: restauração de backup, logs do banco, reconstituição por vínculos e o custo de aceitar a perda.
- Tabela de apoio sem dono: como atribuir responsabilidade — Descreve como identificar quem usa, quem altera e quem responde por uma tabela de apoio órfã, com critérios de posse, registro de mudanças e rotina de revisão.
- Duas fontes para o mesmo indicador: como escolher a base — Definição de qual das duas fontes passa a valer para um indicador, o que a escolha exige em registro e o que ocorre com a base que perde a disputa.
- Planilhas divergentes: o que exigir na contratação — Critérios para contratar a correção de planilhas divergentes, definindo entregáveis de processo e regras de negócio antes de escolher ferramentas.