Calendário, anos bissextos e a matemática por trás disso tudo
O último ano bissexto foi 2024. O próximo será 2028. Parece simples, mas quem já precisou lidar com datas programaticamente sabe que a coisa não é tão trivial quanto parece. A regra básica que todo mundo aprende na escola é: ano divisível por 4 é bissexto, exceto anos de século que não forem divisíveis por 400. Ou seja, 2024 é bissexto, 2000 também foi, mas 1900 não foi. Simples. Na prática, essa simplicidade esconde uma série de problemas. Eu já perdi tempo demais debugando porque um sistema legado em Java 6 interpretava datas de fevereiro de forma errada em determinados contextos de fusos horários. O problema específico foi com a conversão de epoch timestamps para datas locais usando o fuso horário do servidor na America/Sao_Paulo em 2024. A data final ficava deslocada em um dia porque a biblioteca estava lidando mal com o dia 29 de fevereiro durante a passagem para o horário de verão, que naquele ano começou em outubro. A solução foi forçar explicitamente o uso do calendário gregoriano projetado em UTC antes de qualquer conversão local, usando Calendar.getInstance(TimeZone.getTimeZone("UTC")) e só depois aplicar o fuso desejado.
Como calcular se um ano é bissexto em qualquer linguagem
A lógica é sempre a mesma, não importa a linguagem. O código fica basicamente assim: verifica se o ano é divisível por 4, e se for, verifica se não é um ano de século não divisível por 400. Em pseudo-código: (ano % 4 == 0) && ((ano % 100 != 0) || (ano % 400 == 0))
Se quiser fazer de forma ainda mais eficiente, pode usar a lógica reversa: um ano não é bissexto se for divisível por 100 mas não por 400. Isso evita uma condição extra na maioria dos casos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Dados práticos e armadilhas comuns
Aqui estão coisas que você provavelmente não vai encontrar em explicações básicas. Primeiro, o ano bissexto não é perfeitamente regular. O ciclo de 4 anos é uma aproximação da média real do ano trópico, que é de aproximadamente 365,24219 dias. Por isso existem essas exceções de século e de 400 anos. Sem elas, o calendário se desfalsaria cerca de um dia a cada 100 anos. Segundo, muitas bibliotecas de datas têm comportamento estranho com o dia 29 de fevereiro. Por exemplo, se você adicionar um ano à data 29/02/2024 em algumas implementações, o resultado pode ser 28/02/2025 ou até 01/03/2025, dependendo de como a biblioteca lida com overflow. O padrão ISO 8601 não especifica esse comportamento explicitamente, então cada implementação faz do seu jeito. Sempre teste com datas de fevereiro em transições de anos bissextos para não bissextos e vice-versa.
Outro ponto: sistemas que calculam idade ou duração baseada em anos frequentemente erram no ano bissexto. Se seu sistema diz que alguém nasceu em 29/02/2004 tem X anos em 28/02/2025, ele pode estar errado dependendo da lógica de comparação. A abordagem correta é comparar mês e dia, tratando 29/02 como equivalente a 28/02 em anos não bissextos.
O que acontece nos próximos anos
O último ano bissexto anterior a 2028 foi mesmo 2024. Os próximos serão 2028, 2032, 2036 e assim sucessivamente, sem nenhuma surpresa nas regras atuais do calendário gregoriano. A única mudança relevante nas próximas décadas envolve a possibilidade de ajustes no UTC por causa de segundos intercalares, mas isso afeta apenas a precisão dos relógios atômicos, não o calendário civil em si. Se você está construindo algo que precisa manipular datas com frequência, recomendo usar bibliotecas modernas como a java.time do Java 8+, o DateTime do Python ou a biblioteca Temporal do JavaScript. Todas lidam corretamente com anos bissextos, enquanto versões mais antigas dessas mesmas bibliotecas tinham bugs conhecidos nesse quesito. Em resumo, verifique sempre a versão da sua biblioteca de datas antes de confiar nela cegamente.
