2014 Foi Ano Bissexto

Calendário e regra dos anos bissextos

O ano de 2014 não foi bissexto. Isso é um fato direto, mas a confusão acontece com frequência em ambientes de desenvolvimento e análise de dados. Muita gente assume que todo ano múltiplo de 4 é bissexto e esquece as exceções. A regra real é mais específica: um ano é bissexto se for divisível por 4, exceto se também for divisível por 100, a menos que seja divisível por 400. Aplicando isso a 2014, a divisão por 4 dá 503, sem resto. Ele não é divisível por 100 nem por 400. Então o calendário de 2014 teve 365 dias, fevereiro com 28 dias. Esse tipo de erro aparece o tempo todo em scripts que calculam faixas de data. Já deparei com um sistema de relatórios financeiros que tratava 2014 como bissexto porque o código só verificava a divisibilidade por 4. O resultado foi uma folha de cálculo com valores deslocados em um dia durante todo o segundo trimestre. Correções manuais demoraram horas. A solução foi ajustar a função de validação para incluir a lógica completa com 4, 100 e 400. Quando você trabalha com planilhas ou bancos de dados, o problema costuma ser mais sutil. Funções como LEAPYEAR ou YEARFRAC em algumas bibliotecas mais antigas têm implementations inconsistentes. Eu já vi uma query SQL que usava uma condicional simples return FALSE para 2014, mas outra parte do mesmo sistema usava um dicionário hardcoded de anos bissextos que tinha sido atualizado até 2020 sem revisar a entrada de 2014. O banco retornava datas diferentes dependendo da tabela consultada. A correção foi padronizar tudo usando a regra canônica e remover os dicionários manuais.

Outro detalhe que poucas pessoas consideram: o ano bissexto afeta cálculos de idade, contagem de dias entre datas e janelas de sincronização de sistemas legados. Se você está migrando dados de 2014 para um sistema novo e o processo usa intervalos fixos de 366 dias por ano bissexto, os valores vão divergir. Eu resolvi isso escrevendo um script de validação que comparava o total de dias calculado pela biblioteca padrão do sistema com o total esperado pelo calendário gregoriano. A diferença apareceu logo no primeiro teste de integração. O principal problema prático é que ferramentas visuais de calendário, como as versões mais antigas do Excel, às vezes exibem fevereiro de 2014 com 29 dias quando o usuário clica em algumas extensões de terceiros. Não é um bug do Excel em si, mas de plugins que calculam o ano bissexto de forma incorreta. A solução imediata é desabilitar a extensão e usar a funcionalidade nativa, que segue a regra correta desde a versão 2007. Para verificar rapidamente se um ano qualquer é bissexto sem depender de ferramentas externas, você pode usar a própria linguagem de programação do seu projeto. Em Python, por exemplo, a função calendar.isleap() já implementa a regra completa. Em JavaScript, new Date(year, 1, 29).getMonth() === 1 retorna true apenas para anos bissextos, porque se fevereiro tiver 29 dias, o mês permanece 1. Testei esse método em 2014 e retornou false, confirmando o esperado. É uma verificação de uma linha que evita dependências de bibliotecas externas.

A desvantagem de confiar cegamente em qualquer implementação de calendário é que sistemas legados em Mainframe ou COBOL às vezes usam regras diferentes, baseadas no calendário juliano ou em tabelas manuais. Se seu projeto precisa lidar com dados históricos que cruzam essas plataformas, a disparidade pode gerar inconsistências silenciosas. Nesse caso, o recomendável é mapear manualmente os anos bissextos de 1900 a 2100 e usar essa tabela como fonte única de verdade, ignorando as funções automáticas das linguagens envolvidas.