Calendário e anos bissextos
O sistema de anos bissextos existe porque o ano solar não tem exatamente 365 dias. Ele dura cerca de 365,24219 dias, então a cada quatro anos se adiciona um dia em fevereiro para manter a sincronia com as estações. A regra básica é: se o ano é divisível por 4, ele é bissexto, exceto se também for divisível por 100. E se for divisível por 400, aí sim é bissexto. Anos como 2000 foram bissextos, mas 1900 não foi. Essa regra veio do calendário gregoriano, estabelecido em 1582 pelo papa Gregório XIII, que substituiu o juliano justamente para corrigir um desvio acumulado de dias.
quando fevereiro tem 29 dias
Na prática, isso significa que fevereiro tem 29 dias em anos bissextos. Simples assim. O problema é que quase todo mundo decora a regra de forma incompleta e esquece da exceção do século. Eu já vi programadores escreverem código que assume que qualquer ano divisível por 4 é bissexto e depois passam horas caçando bugs em sistemas legado quando um 1900 ou 2100 aparece em alguma data histórica. Uma coisa que muita gente não leva a sério é a questão dos fusos horários. Se você trabalha com dados globais e precisa calcular diferenças de datas entre sistemas que rodam em zonas diferentes, o dia 29 de fevereiro pode aparecer em um fuso e não aparecer em outro se a conversão cruzar uma fronteira horária no momento exato da virada. Já tive um sistema de agendamento que marcava consultas em 29 de fevereiro em São Paulo mas, quando convertido para UTC, voltava como 28 de fevereiro porque a operação caiu em horário negativo. A solução foi padronizar todas as datas internamente em UTC e só converter para o fuso local na apresentação final. Isso costuma resolver 90% desses casos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que vejo sendo ignorado em documentos técnicos: a precisão. O calendário gregoriano já tem um pequeno erro residual — ele adiciona um dia a cada 4 anos, o que na verdade deixa o ano médio com 365,2425 dias, enquanto o ano tropical é 365,24219. A diferença é de cerca de 26 segundos por ano. Isso significa que, ao longo de milhares de anos, o calendário vai se desalinhando novamente. Existe proposta de reforma do calendário, mas nada foi adotado oficialmente. Para uso prático atual, o erro é irrelevante. Se você está construindo algo que precisa lidar com datas, use bibliotecas de data/hora existentes em vez de implementar a lógica do zero. A função calendar.isleap() do Python, por exemplo, já implementa corretamente toda a regra gregoriana. Se você estiver em JavaScript, o new Date(year, 2, 0).getDate() retorna o número de dias de fevereiro naquele ano, embora essa seja uma técnica não tão intuitiva. Em Java, LocalDate.isLeapYear() é a opção mais limpa.
O principal alerta é: não confie em divisões simples. Validar se um ano é divisível por 4 parece suficiente para a maioria dos casos, mas qualquer sistema que processe datas históricas ou futuras com abrangência temporal maior que algumas décadas vai bater de frente com as exceções dos séculos. Esse é o erro mais comum em code reviews que eu vejo.
