Data Em Inglês Formato

Formatando dados em inglês: o que ninguém te conta

Quando você trabalha com dados que vêm de sistemas americanos ou em formato inglês, a primeira coisa que quebra é a separação decimal. No inglês, vírgula é milhar e ponto é decimal. No português brasileiro, é exatamente o oposto. Parece óbvio, mas eu ainda vejo gente tentando importar arquivos CSV dos EUA direto no Excel e se perguntar por que os números estão todos errados.

Por que o data em inglês formato incomoda tanto

A confusão começa porque não existe um padrão único de "formato inglês". Tem o US English (mm/dd/yyyy, 1.000,50) e o UK English (dd/mm/yyyy, 1.000,50), e eles divergem exatamente na parte das datas. Se você está num projeto com dados de múltiplas fontes, vai encontrar os dois tipos misturados num mesmo banco e leva horas pra descobrir o que veio de onde. Eu perdi dois dias num migração de dados porque o arquivo de exportação do sistema legado usava vírgula como separador decimal mas ponto como separador de milhar, e o script de transformação que eu tinha escrito assumia o inverso. O dado "parecia" certo visualmente, mas os valores numéricos estavam todos escalados por mil. A correção foi simples — normalizar tudo com uma regex antes de qualquer conversão — mas eu só percebi quando as somas não batiam com o relatório financeiro.

Data em inglês formato: as regras básicas

Para trabalhar com dados em inglês, você precisa padronizar três coisas: datas, números e a codificação dos arquivos. O resto é consequência. DateFormat em formato americano segue o padrão MM/DD/YYYY. A parte do mês vem antes do dia, e o separador é barra. Já no Reino Unido a ordem é DD/MM/YYYY, idê ntica à brasileira, mas com barras no lugar de traços. É essa ambiguidade que causa os erros mais caros.

Números usam ponto para decimais e vírgula para milhares. O valor 1.234,56 em inglês significa mil duzentos e trinta e quatro vírgula cinco seis. Em português, esse mesmo texto seria interpretado como um milhão, duzentos e trinta e quatro milhões e meio se você não prestar atenção.

Como normalizar na prática

O fluxo mais confiável que eu uso é o seguinte: primeiro defino o encoding do arquivo como UTF-8, depois leio usando o separador correto (vírgula ou ponto e vírgula), e então faço uma conversão explícita de cada coluna usando a biblioteca certa. Se você está no mundo Python, o pandas já lida com isso sem dor de cabeça se você passar o argumento decimal="." ao ler o CSV. O problema é que muita gente esquece de passar esse parâmetro e o pandas assume vírgula como decimal, que é o padrão brasileiro. O resultado são colunas com valores string quando deveriam ser numérico.

import pandas as pd

df = pd.read_csv('dados_usa.csv', sep=';', decimal='.')
df['valor'] = pd.to_numeric(df['valor'], errors='coerce')
df['data'] = pd.to_datetime(df['data'], format='%m/%d/%Y')

No Excel a coisa é menos transparente. A solução que funciona é abrir o arquivo via Power Query, definir o local como "English (United States)" no passo de detecção de colunas, e só então transformar os tipos. Tentar formatar as células depois que os dados já estão carregados não resolve porque o Excel já estragou a conversão na importação.

Datas: o ponto cego mais comum

Quase todo mundo erra nas datas. O problema é que mm/dd/yyyy e dd/mm/yyyy produzem o mesmo texto para datas até o dia 12 de qualquer mês. 07/03/2024 pode ser 7 de março ou 3 de julho, dependendo de onde o dado nasceu. A regra prática é: se a data vier de um sistema americano, trate como mês primeiro. Se vier de sistema europeu ou brasileiro, trate como dia primeiro. Quando você não sabe a origem, use uma validação: se o primeiro número for maior que 12, é obrigatoriamente dia/mês. Isso elimina a ambiguidade na maioria dos casos reais.

No mundo JavaScript, o Date.parse() é traiçoeiro porque interpreta strings no formato ISO (YYYY-MM-DD) como UTC mas Strings com barras como local, e o comportamento varia entre navegadores. Eu vi um dashboard quebrar porque o Chrome lia 01/02/2024 como janeiro e o Firefox lia como fevereiro. A solução segura é nunca confiar no parse automático e usar uma função explicita com bibliotecas como date-fns ou Luxon.

Currency e formatação monetária

Dólar e real seguem convenções opostas também. 1.000,00 USD é distinto de R$ 1.000,00 pelo símbolo antes do número, mas quando o símbolo some, fica impossível distinguir sem saber o contexto. Sempre inclua a moeda como campo separado nos seus dados normalizados. Para exportação, use o padrão ISO 4217 (USD, BRL, EUR) em vez de símbolos. Símbolos como $ causam confusão porque aparecem em pelo menos cinco moedas diferentes. Esse é um erro que eu cometi no início e depois passei anos corrigindo em datasets herdados.

Arquivos CSV e delimitadores

CSV em inglês geralmente usa vírgula como separador de campos, mas muitos sistemas americanos exportam usando ponto e vírgula quando os dados contêm casas decimais com vírgula, para evitar conflito. A única forma de ter certeza é verificar as primeiras linhas do arquivo bruto, sem abri-lo em nenhuma interface que faça formatação automática. Se você precisa converter um arquivo CSV de formato americano para brasileiro e vice-versa, não use substituição cega de caracteres. Substituir todos os pontos por vírgulas e vice-versa destrói os dados. O algoritmo correto é: identificar a estrutura (quantos pontos/vírgulas há por campo), determinar qual é o separador decimal com base na posição, e então reescrever o campo inteiro como string, convertendo depois.

Erros que eu cometi e que você pode evitar

Num projeto de agregação de dados financeiros, eu importei planilhas de três fornecedores diferentes num único dataframe. Dois usavam formato americano e um usava formato brasileiro. O terceiro fornecedor não documentava o padrão. As médias calculadas estavam todas erradas porque o pandas estava tratando valores como string e ignorando durante o aggregate. Só identifiquei o problema quando o total geral bateu com uma planilha de conferência manual. A lição foi simples: nunca confie na inferência automática de tipos. Defina o schema antes de ler qualquer dado. Outro erro clássico é assumir que uma API retorna datas em UTC. Muitas APIs americanas retornam timestamps em fuso horário local e deixam essa informação implícita. Se você não anotar o fuso na hora da ingestão, comparações temporais ficam inconsistentes. Eu resolvi isso adicionando uma camada de metadata que registra a fonte e o fuso de cada campo data no momento da chegada dos dados.

Data em inglês formato: checklist rápido

• Defina encoding como UTF-8 antes de qualquer leitura
• Identifique a origem dos dados para saber se é MM/DD/YYYY ou DD/MM/YYYY
• Sempre especifique o parâmetro decimal na leitura de CSV
• Use bibliotecas de data com parsing explícito, nunca funções genéricas
• Mantenha a moeda como campo separado, nunca como parte do número
• Valide datas ambíguas (dia
• = 12) com regras heurísticas
• Documente o fuso horário junto com cada timestamp

Normalizar dados em formato inglês leva tempo no início mas evita retrabalho massivo depois. Um projeto que eu fiz, onde normalizei cerca de 50 mil registros vindos de dez fontes diferentes, levou aproximadamente quatro horas de configuração inicial e mais uma hora de validação. Depois disso, qualquer carga nova levava menos de dez minutos porque o pipeline já estava parametrizado. O ganho real não está na velocidade de conversão isolada, mas em não precisar refazer a conversão toda vez que um novo arquivo chega. Se você está começando agora, o caminho mais seguro é criar uma função de normalização reutilizável que aceite o formato de entrada como parâmetro, em vez de hardcodar Suposições. Assim quando o próximo arquivo vier com formato inesperado, você ajusta o parâmetro e não reescreve o código.