A conta que ninguém quer fazer todo ano
A Terra leva aproximadamente 365,2422 dias para dar uma volta completa ao redor do Sol. Isso significa que o calendário de 365 dias perde quase um quarto de dia a cada ano. Depois de quatro anos, esse atraso acumula cerca de 24 horas — então adicionamos um dia a mais em fevereiro. O mecanismo é simples, mas a implementação tem particularidades que confundem muita gente. Em termos técnicos, um ano trópico corresponde a 365 dias, 5 horas, 48 minutos e 45 segundos. Se simplesmente adicionássemos um dia a cada quatro anos sem nenhuma exceção, estaríamos inserindo um dia extra a cada 128 anos em média, o que geraria um descompasso de cerca de um dia a cada séculos. Por isso as regras de divisibilidade existem.
pq existe ano bissexto e como a regra funciona na prática
O ano é bissexto se for divisível por 4, exceto se for divisível por 100, a menos que também seja divisível por 400. Anos como 1600 e 2000 foram bissextos. 1700, 1800 e 1900 não foram. O próximo ano a cair nessa exceção do século será 2100, e ele não será bissexto. Na minha experiência lidando com sistemas de datas, o maior problema que vejo é gente programando a lógica manualmente usando condicionais escritas por conta própria. Eu já vi código legado que verificava apenas `ano % 4 == 0`, o que gerava erros de agendamento em anos como 1900 em dados históricos. A correção foi implementar a regra completa ou, preferencialmente, usar bibliotecas de data como a `datetime` do Python ou `java.time` do Java, que já tratam disso internamente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que pouco gente sabe: a regra civil (Gregoriana) é uma aproximação. O ano solar real tem cerca de 365,24219 dias, enquanto a regra Gregoriana calcula uma média de 365,2425 dias. A diferença é minúscula — cerca de 26 segundos por ano — e só se acumula para algo relevante daqui a milhares de anos. Não é problema pra você hoje. Se você precisa verificar bissextos em um script, use a função nativa da linguagem. Em Python: `calendar.isleap(ano)`. Em JavaScript: `new Date(ano, 1, 29).getMonth() === 1` é um truque que funciona mas é feio; o ideal é `Date.isLeapYear` em bibliotecas como Luxon ou moment, ou simplesmente construir a data e verificar se fevereiro tem 29 dias. Em SQL, a maioria dos SGBDs tem funções próprias — não reinvente a roda.
O lado negativo dessa abordagem civil é que calendários religiosos e históricos usam regras diferentes. O calendário Juliano, anterior ao Gregoriano, tinha apenas a regra do divisível por 4. Se você está trabalhando com documentação histórica anterior a 1582, precisa lidar com a transição de calendário, que ocorreu em datas diferentes em cada país — a Grã-Bretanha, por exemplo, só adotou o Gregoriano em 1752, o que causou aquele famoso "perda de 11 dias" nos registros da época. Eu encontrei um banco de dados com registros de nascimento que ficavam "desaparecendo" entre setembro e outubro de 1752 porque a conversão não havia sido feita corretamente. Abaixo está um exemplo prático em Python que implementa a regra completa:
```python def is_leap_year(year): return (year % 4 == 0 and year % 100 != 0) or (year % 400 == 0) ```Isso resolve 99% dos casos. Se o seu sistema precisa lidar com calendários lunares, siderais ou históricos, aí o problema fica muito mais complexo e você provavelmente vai precisar de uma biblioteca especializada como a `dateutil` ou `pytz` para conversões adequadas.
