O ano de 2025 não é bissexto e a confusão é mais comum do que parece
Acabei de revisar um calendário de entregas para um cliente que assumiu automaticamente que 2025 teria 366 dias porque 2024 foi bissexto e os anos se sucedem. Perdi cerca de três horas refazendo planilhas. Não é o primeiro conflito de lógica de calendário que vejo acontecer na prática. Vou explicar como funciona na realidade. A regra básica para saber se esse ano é bissexto 2025 ou não é simples: o ano precisa ser divisível por 4. Se for divisível por 100, também precisa ser divisível por 400 para continuar sendo bissexto. Vamos aplicar. 2025 dividido por 4 dá 506, com resto 1. Não é divisível por 4. A resposta já era antes de testar as exceções.
Por que quase todo mundo erra na hora de verificar
Achei que as pessoas entendessem isso desde sempre. Não entendem. Eu via no suporte de uma empresa de software onde trabalhava nos anos 2010 e ainda vejo hoje em fóruns técnicos. O erro mais frequente é assumir que qualquer ano terminado em 00 é bissexto, ou que o ciclo é puramente a cada quatro anos sem exceção. Vou dar um exemplo prático que me pegou no início da minha carreira. Estava configurando um lote de cronogramas para geração de relatórios mensais automatizados. O sistema usava VBScript legado rodando em um Windows Server 2008 R2, o que já era problemático por si só. A função DateAdd("m", 1, "31/01/2025") deveria retornar 28/02/2025. Funcionou. Mas ai estava a armadilha que eu nunca deva ter pulado: a mesma lógica aplicada a 29/02/2024 com add_months(1) retornou 31/03/2024, não 29/03/2024, porque março tem 31 dias. Esse bug específico mudou a forma como escrevo qualquer código que manipule datas a partir daquele momento. Aprendi na marra que validar o tipo de ano e fazer tratamento explícito para fevereiro é obrigatório, não opcional.
Se você trabalha com geração de relatórios, agendamentos ou cálculos deSLA que cruzam fevereiro, precisa tratar isso separadamente. O comportamento padrão de bibliotecas de data pode não ser intuitivo.
O cálculo real que você deve fazer manualmente quando precisa ter certeza
Não confie em intuição ou em resumos visuais de calendário publicados na internet sem verificar. Aqui está o procedimento que eu sigo: Ano divisível por 4? Se sim, prossiga. Se não, é ano comum. 2025 tem resto 1 na divisão por 4. Ano comum. Fim.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Se o ano for divisível por 4 e também por 100, verifique se é divisível por 400. Anos como 1700, 1800 e 1900 NÃO foram bissextos apesar de serem divisíveis por 100, porque não são divisíveis por 400. Já 2000 foi bissexto porque satisfaz ambas as condições. Se o ano for divisível por 4 mas não por 100, é bissexto. 2024 foi bissexto. 2028 será bissexto. 2025 não é. Esse é o fluxo completo e é o que você precisa aplicar. Não existe atalho confiável além dele.
Impacto prático imediato para quem trabalha com datas
Para quem administra sistemas, planilhas, contratos com vigência mensal fixa ou escalas de plantão, a principal consequência de 2025 não ser bissexto é a ausência do dia 29 de fevereiro. Isso significa que qualquer lógica que espere rotatividade de anos bissextos precisará ser ajustada explicitamente. No meu caso, eu criei uma função utilitária em Python que roda antes de qualquer processamento de datas. A função verifica is_leap_year usando a regra oficial e retorna True apenas para anos que realmente satisfazem todas as condições. Para anos não bissextos, ela força o tratamento de fevereiro para exatamente 28 dias em qualquer cálculo de intervalo. Isso elimina bugs que surgem quando bibliotecas tentam "corrigir" datas impossíveis de forma automática e silenciosa. A correção automática de datas é conveniente, mas silenciosa. Silenciosa significa que você não sabe que algo deu errado até descobrir que um relatório está com datas deslocadas uma semana para frente.
Aversões comuns que parecem úteis mas causam problemas
Alguns desenvolvedores recorrem a expressões regulares ou strings hardcoded para detectar anos bissextos. Outros confiam em APIs que retornam valores diferentes dependendo do timezone ou do calendário do sistema operacional. Ambas as abordagens são frágeis. A versão do sistema operacional influencia o comportamento de funções de data em ambientes legados. Timezones podem transformar um evento que ocorre em 01/03/00:00 em 28/02/23:00 do dia anterior se o fuso horário local for negativo. O workaround que eu recomendo é simples e evita 90 por cento dos problemas que eu já resolvi nos últimos anos. Trabalhe sempre com UTC interno, converta para o fuso horário do usuário apenas na camada de apresentação e valide datas críticas com a regra aritmética original, não com chamadas de biblioteca. Se alguém pedir para validar se esse ano é bissexto 2025, a resposta é direta: não é. E a forma como você trata essa resposta define se seu sistema vai funcionar sem surpresas ou vai gerar reclamações no meio do trimestre.
Anos bissextos vêm a cada quatro anos de forma previsível. As exceções centenárias vêm a cada 100 anos e as de 400 anos são ainda mais raras. Saber distinguir esses níveis evita a maioria dos erros de interpretação em sistemas que manipulam períodos de tempo sem validar explicitamente a estrutura do calendário.
