O problema prático de saber quando a semana termina
A pergunta parece simples, mas quem já teve que programar relatórios, calcular folgas ou sincronizar APIs com sistemas internacionais sabe que "último dia da semana" não é algo que você resolve com uma pesquisa rápida no Google. Tem gente que usa domingo, tem gente que usa sábado, e tem padrão ISO que define como segunda. A confusão só aumenta quando você precisa que tudo isso funcione junto. Vou explicar como eu lido com isso na prática, porque já gastei duas semanas debugando um bug que era puramente isso: o sistema de RH da empresa usava domingo como fechamento de semana, o banco de dados estava em SQL Server com configuração americana, e o relatório final vinha com os dados desfasados em exatamente um dia. Ninguém notou até o cliente reclamar que o horário extra de sexta estava sendo pago como se fosse de sábado.
Por que a discussão sobre ultimo dia da semana existe
Não existe um acordo universal. A norma ISO 8601, que é a referência técnica mais usada no mundo para datas, define segunda como o primeiro dia da semana e domingo como o sétimo — ou seja, o último. Isso é o que a maioria dos sistemas europeus e asiáticos segue. Nos Estados Unidos e em partes da América Latina, o padrão cultural coloca domingo como o primeiro dia, o que inverte a lógica completamente. No Brasil, a situação é híbrida: a cultura popular frequentemente considera sábado o fim da semana de trabalho, mas sistemas jurídicos e empresariais tendem a seguir o padrão ISO. O ponto que quase ninguém menciona é que a própria língua portuguesa carrega essa ambiguidade. Quando alguém diz "fim de semana", está falando de sábado e domingo juntos, não de um único dia. Isso cria um problema real em interfaces e formulários: o campo "dia da semana" geralmente espera um inteiro de 0 a 6, mas o que cada número representa depende inteiramente da cultura do usuário final.
Como resolver isso no dia a dia
A abordagem que funciona para mim começa com uma decisão clara: eu nunca deixo o sistema deduzir o padrão. Eu defino explicitamente no código qual convenção estou usando e documento isso. O erro que eu cometi naquela ocasião foi confiar no comportamento padrão do SQL Server, que por sua vez herdava a configuração do servidor Windows, que por sua vez seguia o regional do Data Center. Três camadas de suposição, e nenhuma estava correta para o caso de uso. O workaround que eu uso atualmente é bem direto. Eu normalizo todas as datas para ISO 8601 internamente, transformando qualquer input para o formato padrão onde segunda = 0 e domingo = 6. Quando preciso apresentar para o usuário, eu faço a conversão inversa baseada no padrão que aquele usuário espera. Em Python, isso fica assim:
from datetime import datetime, timedelta def ultimo_dia_semana(data, start=0):
dias_para_final = 6 - start return data + timedelta(days=dias_para_final - data.weekday())
👉 Clique no botão abaixo para saber mais sobre o assunto!
Em JavaScript, o mesmo raciocínio, mas com a pegadinha do getDay(), que retorna 0 para domingo em vez de segunda. Se você não prestar atenção nisso, seu código vai funcionar perfeitamente em produção durante meses e depois quebrar quando alguém mudar a regionalidade do servidor. Já vi isso acontecer com APIs de pagamento que usam Date nativo do Node rodando em containers com timezone diferente do desenvolvimento.
Erros comuns que custaram caro para eu aprender
O primeiro erro é pensar que moment.js ou date-fns vão salvar você. Bibliotecas de data têm seus próprios padrões e defaults. A moment.js, por exemplo, usa domingo como primeiro dia por padrão, enquanto o date-fns usa segunda. Se você fizer upgrade ou trocar de biblioteca sem revisar o código, o "último dia da semana" pode mudar de valor sem nenhum aviso no log. O segundo erro, e esse é o mais sutil, é confiar em toLocaleDateString() para determinar o padrão. O método depende do runtime e do ambiente. No navegador do usuário ele vai respeitar a configuração do sistema operacional. No servidor, vai respeitar o locale do Node ou do Python. Quando você tem um sistema distribuído com usuários em dezenas de países, a consistência desaparece rapidamente.
Eu resolvi isso implementando um config centralizado. Existe uma tabela no banco, ou um arquivo de configuração em produção, que mapeia cada usuário ou tenant para um padrão de início de semana. O código lê essa configuração e aplica a conversão. É um pouco mais de trabalho na implementação, mas elimina a variável imprevisível.
Cenários onde essa abordagem falha
A conversão manual baseada em configuração funciona bem para a maioria dos casos, mas tem Limitações que você precisa conhecer. A primeira é quando você consome dados de terceiros. Se uma API de terceiro retorna datas sem contexto cultural e você precisa interpretar o "fim da semana" dela, a configuração local não ajuda. Nesse caso, o mais seguro é solicitar explicitamente o formato ou usar a norma ISO como fallback, assumindo que é o padrão mais neutro disponível. A outra limitação é histórica. Dados antigos, registros criados antes da implementação da normalização, podem ter sido salvos com lógica inconsistente. Eu encontrei isso em um banco de dados com cinco anos de histórico onde os registros dos primeiros dois anos tinham domingos atribuídos a semanas que, pela norma ISO, deveriam pertencer à semana seguinte. Não havia como corrigir automaticamente sem revisar registro por registro. A solução que adotei foi criar uma coluna separada para "semana civil" e deixar a "semana ISO" como padrão, com uma view que faz a equivalência quando necessário.
Se você está começando agora e quer algo mais simples, a alternativa é usar diretamente a norma ISO em tudo, desde o banco de dados até a interface. Isso elimina a maior parte dos problemas, mas exige que sua equipe e seus parceiros entendam que domingo não é mais o dia zero. Para sistemas legados que já operam com outra convenção, o custo de migração pode ser alto demais, e aí a abordagem de configuração centralizada continua sendo a menos dolorosa.
