O primeiro dia da semana nas planilhas e no código
Se você trabalha com relatórios recorrentes, agendamentos ou sistemas que geram datas automaticamente, o primeiro dia da semana é uma daquelas coisas que parece boba até dar problema. Eu já perdi umas três horas de uma vez tentando debugar um relatório de folha de pagamento porque o sistema do cliente e a planilha de controle tinham o primeiro dia da semana configurado de forma diferente. Um usava domingo, outro segunda. O resto você imagina.
O que é primeiro dia da semana e por que isso importa
O conceito é simples: em alguns contextos culturais e legais, a semana começa no domingo. Em outros, começa na segunda. A ISO 8601 define segunda como o primeiro dia. Mas definições técnicas não resolvem o problema na prática, porque softwares e planilhas seguem culturas diferentes. No Excel, por padrão, a função COISADIA (WEEKDAY) considera domingo como o dia 1. Se você passar o parâmetro 2, a semana começa na segunda. Isso já confunde muita gente que não lê a documentação. No Google Sheets acontece o mesmo. No SQL Server, a função DATEPART com weekday retorna 1 para domingo em muitas configurações regionais. Em Python, o datetime.weekday() retorna 0 para segunda e 6 para domingo. Em JavaScript, getDay() retorna 0 para domingo. Você vê o padrão? Cada linguagem trata o primeiro dia de um jeito.
Como configurar corretamente em cada ferramenta
No Excel, se você quer que os cálculos de datas levem em conta segunda como início de semana, o ideal é usar a sintaxe =COISADIA(data;2). O parâmetro 2 redefine a enumeração para começar na segunda. Sem isso, qualquer fórmula que conte dias úteis ou agrupe por semana vai entregar resultado errado silenciosamente. Eu já vi alguém montar uma dashboard inteira de absenteísmo com semana começando em domingo e não perceber que todas as segundas-feiras estavam sendo agrupadas com a semana anterior. No Google Sheets, a lógica é parecida. A função =DIASEM(data;2) também coloca segunda como primeiro dia. A diferença é que o Google Sheets não força a cultura americana em todas as funções de data. Ainda assim, vale a pena verificar manualmente quando for migrar dados entre plataformas.
Em Python, a biblioteca pandas tem o parâmetro week_start no método resample, mas a forma mais comum é usar o atributo isocalendar() ou datetime.isoweekday(), que segue a ISO 8601 e já considera segunda como 1. Quem usa bibliotecas mais antigas pode esbarrar no numpy.datetime64, que também adota a convenção ISO por padrão. O problema é quando você recebe dados de uma fonte externa que veio formatada com a convenção americana. No SQL, a configuração é mais traiçoeira porque depende de session settings. No SQL Server, o SET DATEFIRST define qual dia é o primeiro. O padrão varia conforme a language do login. Se o login estiver como us_english, DATEFIRST é 7 (domingo). Se for brazilian_portuguese, o padrão costuma ser 1 (segunda). Eu tive um caso em que um job do SQL Server rodava em um servidor com login configurado para inglês americano e gerava relatórios semanais começando no domingo, enquanto o analista local esperava segunda. O job funcionava tecnicamente perfeito, só que o relatório estava mentalmente errado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que ninguém te conta
O primeiro erro é assumir que seu software segue a ISO 8601. Muito software não segue. Planilhas comerciais, ERPs de pequeno porte, ferramentas de RH antigas — muitos deles usam domingo como referência por herança de padrões americanos. Se você está integrando dois sistemas e um deles usa uma convenção e o outro outra, a integração vai "funcionar" mas os dados vão estar deslocados. Eu já vi um relatório de vendas que tinha toda a primeira semana do mês deslocada por um dia porque o ERP de origem considerava domingo como início e a ferramenta de BI considerava segunda. O segundo erro é não documentar qual convenção foi usada em cada etapa do pipeline de dados. Quando você monta um fluxo que passa por várias etapas — extração, transformação, carga — e em cada uma delas o primeiro dia da semana é tratado de forma diferente, o resultado final fica imprevisível. A solução mais prática é normalizar tudo para ISO 8601 logo na entrada dos dados e manter essa convenção do início ao fim.
Outro problema real é a questão dos feriados e semanas parciais. Quando você calcula uma semana que começa em domingo e termina em sábado, mas o feriado cai na segunda-feira, a soma de horas trabalhadas ou vendas daquele período pode parecer estranha se você não tratar o feriado explicitamente. Eu trabalhei num projeto em que a empresa precisava reportar a produtividade semanal para o sindicato, e o sindicato exigia que a semana começasse na segunda, enquanto o sistema de ponto da empresa registrava tudo baseado no domingo. A conciliação demorou duas semanas só para acertar a regra de truncamento dos domingos que ficavam no início da semana civil.
Quando a convenção errada causa dano real
Eu tenho um caso específico que marca bastante. Trabalhávamos com folha de pagamento de uma empresa que tinha filiais em dois estados com regimes de compensação horária diferentes. Uma filial usava o ponto semanal de domingo a sábado, outra de segunda a domingo. Quando migramos o cálculo para um sistema novo, o desenvolvedor configurou tudo baseado na convenção ISO, ou seja, segunda como início. O sistema novo processou a filial que usava domingo como referência de forma errada durante três meses. Só descobrimos quando o RH percebeu que os funcionário daquela filial estavam com horas extras calculadas deslocadas. O workaround foi criar uma flag por filial no banco de dados e tratar cada caso com uma função específica que ajustava a data de início da semana conforme a convenção local antes de qualquer cálculo. Isso mostra que não existe solução única. O que funciona para uma empresa pode falhar para outra. Se você está construindo um sistema do zero, a recomendação mais segura é adotar ISO 8601, mas deixar configurável para quando o cliente exigir outra convenção. Não adianta insistir que "o certo" é sempre segunda, porque o mundo real não funciona assim.
Checklist rápido para evitar dor de cabeça
Verifique qual convenção sua ferramenta usa por padrão antes de começar qualquer projeto de datas. Anote isso em algum lugar visível. Se for trabalhar com múltiplas fontes de dados, normalize tudo para uma única convenção o mais cedo possível. E, acima de tudo, teste com datas de transição de semana — especialmente datas que caem no fim de semana — porque é aí que os bugs aparecem. Um test case com data 01/01/2024, por exemplo, já revela se sua configuração está consistente, porque esse dia caiu em segunda-feira e qualquer desalinhamento vai aparecer claramente nos agrupamentos semanais. Se quiser algo prático para conferir rapidamente, dá para usar uma query simples no SQL ou uma fórmula no Excel só para listar os dias de uma semana e ver se a enumeração bate com o que você espera. Gasta dois minutos e evita duas horas de correção depois.
