Calculando um mês a partir de 31 de janeiro: o problema que todo mundo encontra
Se você nasceu em 31 de janeiro e quer saber exatamente quando faz um mês de vida, a resposta depende de qual sistema você está usando. A maioria das pessoas espera que seja 31 de fevereiro e para por aí. O problema é que fevereiro não tem 31 dias, então qualquer calculadora séria precisa tomar uma decisão. Essa decisão varia. No Brasil, o costume jurídico e o mais usado no cotidiano segue a regra do último dia do mês subsequente. Então, para quem nasce em 31 de janeiro, o primeiro mês se completa em 28 de fevereiro (ou 29 em anos bissextos). É assim que cartórios, planos de saúde e sistemas governamentais tratam a questão na prática. Não é uma lei específica, é convenção consolidada que aparece em decisões do STJ e nas notas técnicas do Departamento de Registros Públicos.
quem nasce dia 31 de janeiro faz 1 mês quando
A resposta curta: 28 de fevereiro em anos normais e 29 de fevereiro em anos bissextos. Se você tá usando uma planilha ou um sistema que não segue essa convenção, provavelmente vai receber uma data errada ou um erro de validação. Já vi isso acontecendo com frequência em folhas de ponto e cadastros de clínica. Na programação, a coisa fica mais confusa. Bibliotecas diferentes resolvem o problema de jeitos diferentes. Vou dar os exemplos mais comuns que encontrei na minha experiência:
👉 Clique no botão abaixo para saber mais sobre o assunto!
JavaScript (Date object): Se você fizer new Date(2024, 0, 31) e somar um mês com setMonth(getMonth() + 1), o resultado será 28 de março de 2024, não 28 de fevereiro. Isso acontece porque janeiro tem 31 dias, o código tenta criar 31 de fevereiro, que não existe, e o JS "estoura" para o mês seguinte, voltando ao dia 28 de março. Parece um bug, mas é o comportamento padrão do ECMA-262. Para corrigir, a workaround que eu uso é verificar se o dia mudou após a soma dos meses. Se mudou, volta para o último dia do mês correto. Python (dateutil.relativedelta): Aqui a coisa funciona melhor. relativedelta(months=1) respeita a convenção do último dia do mês. Resultado: 28 de fevereiro de 2024. Mas se você usar timedelta(days=30), vai cair em 2 de fevereiro, que tecnicamente também não é "um mês" no sentido calendário. A diferença entre os dois métodos é enorme e muita gente não percebe.
Excel/Google Sheets: A função DATE(YEAR(data); MONTH(data)+1; DAY(data)) tem o mesmo comportamento do JavaScript — ela estoura para o mês seguinte quando o dia não existe. A solução no Excel é envolver com EOMONTH: DATE(YEAR(data); MONTH(data)+1; 0) te dá o último dia do mês seguinte diretamente, sem surpresas. O que poucas pessoas levam em conta é que não existe uma regra única universal. Diferentes países, diferentes linguagens e até diferentes setores dentro do mesmo país usam convenções distintas. No direito português, por exemplo, a contagem de prazos segue regras próprias que podem diferir da prática brasileira. Se você está construindo um sistema que atende múltiplos mercados, precisa decidir qual convenção adotar e documentar isso explicitamente, senão vai ter dor de cabeça com usuários reportando datas "erradas".
Outro ponto prático: em formulários de cadastro, muitos sistemas simplesmente bloqueiam a entrada de datas como 31 de fevereiro. Isso força o usuário a escolher entre ajustar manualmente ou aceitar que o campo não reconhece a data de nascimento. A solução mais robusta que eu vi foi fazer a validação no backend usando EOMONTH ou equivalente, permitindo o cadastro e só convertendo para a convenção correta na hora da consulta. Assim o histórico fica intacto e os cálculos posteriores não quebram. Se o seu uso é puramente pessoal e você quer apenas saber a data, a resposta simples é 28 de fevereiro (ou 29). Se é para construir algo que precisa funcionar corretamente, entenda qual convenção seu sistema usa antes de confiar no resultado. A maioria dos erros que eu vejo acontecem exatamente aqui: alguém assume que o código vai se comportar de um jeito e ele se comporta de outro.
