Calculando a quantidade de dias de um ano
esse ano teve quantos dias
O ano atual, 2026, tem 365 dias. Não é bissexto. A resposta curta já está dada, mas o que vale a pena explicar é como se chega nela de forma confiável, porque em sistemas reais isso parece simples até você ver o banco de dados falhar no dia 29 de fevereiro de um ano que não existe. A regra básica dos anos bissextos no calendário gregoriano é: o ano é bissexto se for divisível por 4, exceto se for divisível por 100 mas não por 400. Então 2024 foi bissexto com 366 dias, 1900 não foi e teve 365, mas 2000 foi e teve 366. Qualquer coisa além disso é ajuste fino para satélites ou calendários legais em jurisdições específicas, o que rara mente é seu problema.
Na prática, a forma mais segura de descobrir quantos dias tem um ano num projeto é deixar o próprio motor de datas fazer o cálculo. Num cenário real que eu enfrentei, tínhamos uma rotina que montava intervalos de datas juntando anos de várias fontes — algumas com year=0, outras truncadas, outras vindo de arquivos CSV com zeros à esquerda que o Python lia como string. O resultado era um range que ia de 0001 a 9999 de repente, e o código que contava dias por ano simplesmente quebrava em datas inválidas. A solução foi tratar o campo ano como inteiro com validação explícita antes de construir qualquer datetime, e usar o cálculo de forma isolada: Pegar o primeiro dia do próximo ano e subtrair o primeiro dia do ano em questão. O Python com datetime resolve isso sem margem para erro se você já tem a entrada limpa. Se você estiver num contexto onde não quer depender da biblioteca padrão, o cálculo direto é igualmente simples. Você testa se o ano é bissexto com a regra acima e devolve 366 ou 365. Aqui está a lógica numa linha: 366 se (ano % 4 == 0 e ano % 100 != 0) ou (ano % 400 == 0), senão 365. Isso funciona para o intervalo completo do calendário gregoriano, de 1582 pra frente, e na maioria dos casos práticos até 1 a 9999, que é o limite suportado pela maioria das bibliotecas de datas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Há uma pegadinha que gente nova costuma errar: assumir que todos os anos divisíveis por 4 têm 366 dias. O ano 2100 vai cair nessa armadilha se você usar apenas year % 4 == 0. Ele não é bissexto e tem 365 dias. Se o seu sistema não considerar a exceção dos séculos, relatórios de folha de pagamento ou agendamentos futuros vão acumular erro de um dia a cada século. Não é grave agora, mas é grave se o software tiver que rodar até 2100 sem revisão. Outro detalhe prático diz respeito a fusos horários. Contar dias de um ano normalmente não é afetado por isso, mas se você estiver trabalhando com timestamps em UTC e precisando converter para um fuso local que teve mudança de horário durante o ano, a contagem de eventos por dia pode mostrar 23 ou 25 horas em alguns dias específicos. O número de dias do ano em si não muda, mas a contagem de registros por dia pode parecer inconsistente se você não normalizar tudo para UTC antes de agrupar por data.
Para quem usa SQL, a abordagem mais direta varia conforme o SGBD. No PostgreSQL, você pode gerar uma sequência de datas com generate_series e agrupar por ano, ou simplesmente calcular a diferença entre o primeiro dia do ano seguinte e o primeiro dia do ano atual. No MySQL, date_add com interval 1 year funciona bem. Em qualquer um deles, garantir que a coluna de data não tenha valores nulos ou fora do range válido evita surpresas. Se o seu caso for puramente estatístico e você precisar contar dias por ano em grandes volumes de dados, considere pré-calcula o número de dias de cada ano e armazenar numa tabela de consulta rápida. Um lookup de dicionário com {2024: 366, 2025: 365, 2026: 365} é absurdiamente mais rápido do que recalcular a cada linha, e elimina qualquer ambiguidade de biblioteca ou fuso. A desvantagem é que você precisa manter a tabela atualizada quando surgirem requisitos de anos futuros fora da faixa que já cobriu, mas isso acontece raramente.
Resumindo o que importa: 2026 tem 365 dias. A regra dos bissextos explica por quê. E em produção, a maior parte dos problemas não vem da matemática, e sim de dados mal formatados, anos fora do intervalo esperado, ou conversões de fuso que distorcem a contagem por dia.
