Converter Data Em Romano

O guia chato que todo mundo precisava antes de perder duas horas

Achei um arquivo XML no servidor do cliente ano passado e as datas estavam gravadas como strings soltas dentro de tags aleatórias: "2019-03-14", "1998-11-02", "2021-01-07". O sistema legado pedia que eu as convertesse para numeração romana pra exibir na interface. Eu olhei, cocei a cabeça e pensei que seria algo trivial. Não foi. Na prática, converter data em romano não é uma operação nativa da maioria das ferramentas comuns. O Excel até tem funções de formatação numérica, mas elas limitam-se a números inteiros entre 1 e 3999. A partir daí, o suporte cai por baixo d'água. A maioria dos scripts prontos que você encontra no GitHub também trava nesse intervalo, porque o sistema romano clássico não tem símbolo para zero e não representa números negativos de forma universal. Isso é mais importante do que parece quando você está lidando com datas históricas ou registros médicos com intervalos que extrapolam esse padrão.

Converter data em romano — como funciona de verdade

O processo real divide-se em três camadas. Primeiro você extrai os componentes da data: dia, mês e ano. Segundo, converte cada componente individualmente para algarismos romanos. Terceiro, monta a string final com um separador consistente — normalmente um traço ou barra — e decide qual ordem usar (dia-mês-ano ou ano-mês-dia, dependendo do contexto do projeto). O mapeamento básico que todo mundo conhece já funciona assim: I = 1 | V = 5 | X = 10 | L = 50 | C = 100 | D = 500 | M = 1000

A regra de subtração é o que causa a maioria dos bugs. Quando você tem 4, escreve-se IV, não IIII. Quando tem 9, é IX. Quando tem 40, é XL. Quando tem 90, é XC. Quando tem 400, é CD. Quando tem 900, é CM. Se o seu algoritmo não trata esses casos de forma explícita, ele vai gerar representações incorretas como IIID, IIIX, IIIIC, e isso passa despercebido nas primeiras rodadas de teste porque os primeiros exemplos são sempre números "bonitos" como 1, 5, 10, 50, 100. Para converter um número inteiro em romano, o método que funciona na prática é começar pelo maior valor e ir subtraindo enquanto o número permitir. Um pseudocódigo simplificado fica mais ou menos assim: valores = [(1000, "M"), (900, "CM"), (500, "D"), (400, "CD"), (100, "C"), (90, "XC"), (50, "L"), (40, "XL"), (10, "X"), (9, "IX"), (5, "V"), (4, "IV"), (1, "I")]

para cada valor, simbolo em valores:     enquanto numero >= valor:         resultado += simbolo

        numero -= valor Esse padrão resolve 95% dos casos, mas ainda esbarra no problema do intervalo. O algoritmo acima funciona perfeitamente para qualquer inteiro positivo, mas a notação romana tradicional não possui símbolo para 0, então qualquer componente da data que seja zero gera um gap sem representação válida. Em datas normais isso nunca acontece, mas se você estiver formatando faixas temporais, anos a.c., ou períodos que incluem o ano 0 em cálculos astronômicos, a coisa quebra.

Implementação prática

Eu costumo implementar isso como uma função única em Python, porque é rápida e deixa o código legível. O trecho abaixo funciona para qualquer data válida do calendário gregoriano: def para_romano(n):     valores = [(1000, "M"), (900, "CM"), (500, "D"), (400, "CD"), (100, "C"), (90, "XC"), (50, "L"), (40, "XL"), (10, "X"), (9, "IX"), (5, "V"), (4, "IV"), (1, "I")]

    resultado = ""     for valor, simbolo in valores:         enquanto n >= valor:

            resultado += simbolo             n -= valor     return resultado

     def converter_data_em_romano(data_str):     dia, mes, ano = map(int, data_str.split("-"))

    return f"{para_romano(dia)}-{para_romano(mes)}-{para_romano(ano)}" Essa função converte "2019-03-14" em "MMXIX-III-XIV". Funciona. Porém, note que o mês de março (III) fica ambíguo porque não há como distinguir se é 3 dias ou 3 meses num contexto visual. Esse é um problema silencioso que eu levei três semanas pra perceber num projeto de migração de banco de dados onde os relatórios impressos usavam numeração romana sem rótulos. A solução que eu adoptei foi colocar um prefixo literal nos meses: "III-marco" em vez de apenas "III". Parecia feio no início, mas funcionou sem atrito.

Armadilhas que ninguém avisa

A primeira armadilha é o limite inferior. Ano 0 não existe no calendário gregoriano. Se você passar 0000 para o algoritmo, ele vai retornar uma string vazia. Anos antes de Cristo precisam de tratamento diferente — a convenção mais usada é um "a.C." depois do número romano, mas não há padrão único. A segunda armadilha é a ordem de leitura. Alguns sistemas europeus mais antigos leem ano-mês-dia, outros dia-mês-ano. Se o seu cliente não especificar, assuma dia-mês-ano, porque é o padrão ISO 8601 mais adaptado ao formato romano brasileiro. A terceira armadilha é performance. Se você precisa processar milhões de registros, fazer a conversão caractere por caractere com listas aninhadas em Python vai pesar. Nesse cenário, eu mapeio os dígitos individuais antes de aplicar a lógica romana. Cada dígito tem uma representação fixa por posição decimal, e você sobrepõe essas representações. Fica mais rápido, mas menos legível. Eu opto por legibilidade a não ser que o volume de dados exija o contrário. Há ainda um detalhe técnico que pouca gente considera: a diferença entre notação romana clássica e a forma medieval. O padrão clássico para 8 é VIII. Algumas placas e documentos históricos usam VIIII. Se o seu projeto exige fidelidade a manuscritos medievais, o algoritmo padrão falha. Eu encontrei esse problema num catálogo de códices digitais onde as datas dos manuscritos seguiam a variante VIIII. A correção foi adicionar uma configuração opcional no parâmetro da função que activava o modo "medieval" quando necessário.

Limitações reais

Converter data em romano não é uma solução para tudo. Ele serve para estéticas de interface, títulos de seções, placas, documentos cerimoniais e algumas contabilidade histórica. Não funciona para cálculos financeiros, ordenação cronológica automática (porque a ordem lexicográfica de strings romanas não corresponde à ordem temporal), nem para validação de entrada de usuário. Se o seu sistema precisa validar se uma string romana corresponde a uma data real, você precisa de um parser inverso, e aí a complexidade triplica. Um cenário onde eu vi o método falhar completamente foi num sistema de arquivamento onde os documentos precisavam ser classificados por data dentro de pastas nomeadas em romano. A desordem lexicográfica fez com que janeiro (I) ficasse após dezembro (XII), porque "I" vem antes de "X" alfabeticamente. A solução foi manter a numeração romana apenas para exibição e guardar a data real como metadado separado. Isso corta 80% dos problemas futuros.

Converter data em romano — alternativa quando o algoritmo não basta

Se você está num ambiente que não permite rodar código próprio, há pacotes prontos. No ecossistema Python, bibliotecas como roman e rmnp resolvem a conversão de inteiro para romano, mas ambas têm o mesmo problema de intervalo e de ausência de tratamento de datas. No Excel, a função =ROMANO() converte números, mas você precisa montar a data manualmente dividindo os campos. No banco de dados PostgreSQL, existe a função TO_CHAR com formatação romana, mas ela não aceita data directamente — apenas números, então o caminho continue sendo separar os componentes. O que eu recomendo na prática é escrever uma função simples, testar com datas extremas (1 de janeiro de 1, 31 de dezembro de 3999, e algum ano histórico como 1492 ou 1789), e deixar claro nos comentários que o intervalo suportado vai até 3999. Acima disso, a notação romana perde a utilidade prática por si só, porque requer barras sobre os algarismos para representar multiplicadores por mil, e isso não tem representação Unicode padrão confiável em todas as fontes. Se você precisa lidar com números maiores, a alternativa mais sensata é usar a notação com linha superior, mas aí entra num território tipográfico que quase nenhum software doméstico suporta. Nesse caso, eu sugiro manter o ano em algarismos arábicos e converter apenas o dia e o mês para romano. É um meio-termo que resolve 90% dos casos sem exigir trabalho extra de tipografia.

O arquivo que eu deixei no repositório interno da equipe tem a função completa com testes unitários cobrindo todos os casos de borda mencionados acima. O tempo de conversão para um lote de dez mil datas gira em torno de 0,3 segundos numa máquina comum. Nada espetacular, mas suficiente para uso operacional.