Datas e o dia que vale pelo horário de Brasília

É a regra de fundo que decide a que dia um instante pertence. A resposta é sempre a mesma: o dia é o dia de Brasília, nunca o dia em horário universal. O sistema guarda os instantes em horário universal, mas toda pergunta sobre "em que dia isso aconteceu" é respondida pelo fuso de Brasília.

Parece detalhe técnico e não é: é a causa de uma família de reclamações do participante que, sem essa explicação, parecem bug.

Internamente, todas as datas e horas são normalizadas para o horário universal na gravação. O fuso do negócio (Brasília, por padrão) é aplicado em três momentos:

• para decidir a que dia pertence um instante;
• para recortar instantes por dia (em filtros e contagens);
• para exibir o horário de um instante.

A regra é usada de forma obrigatória no motor, nos filtros de período dos relatórios, na pergunta "a campanha está no período" e nas exportações. A única exceção é a data pura — como a data do prêmio de uma posição ou a data de nascimento — que é gravada como data, sem hora, e não passa pelo fuso.

Onde isso muda o resultado

Estes são os pontos concretos em que o atendimento encontra o efeito:

O limite de notas por dia. A cota renova à meia-noite de Brasília. Das 21h à meia-noite, o relógio universal já está no dia seguinte — pelo horário universal, a cota se renovaria três horas antes da virada do relógio de quem está cadastrando.

A data da compra da nota. É comparada por dia de calendário no fuso de Brasília, como o período da campanha. Compra feita às 22h do último dia da campanha continua valendo, mesmo que no horário universal ela já seja do dia seguinte.

O período da campanha. "Está no período" é a mesma pergunta que o validador da nota faz para aceitá-la, e é a mesma que define se a campanha está em andamento para efeito da exigência de Master na alteração de regra. As duas usam o dia de Brasília. O portal de campanhas também usa essa mesma regra para decidir quais campanhas aparecem e quantos dias faltam.

A idade no cadastro. A referência é o dia de Brasília. Perto da meia-noite, pelo horário universal já seria o dia seguinte, e quem faz aniversário amanhã entraria hoje.

A campanha encerrada. É o dia de fim anterior ao dia de hoje, no fuso de Brasília.

A validade de convite. Comparada por dia no fuso de Brasília.

O sorteio pela Loteria Federal. Concorrem os números gerados até a data do sorteio do prêmio. Quando o prêmio não tem data de sorteio, o corte é o início do dia do concurso, no horário de Brasília.

O link das ações de comunidade. O link pessoal da jogada vale até as 23:59 do dia, no horário de Brasília.

Os horários exibidos. O histórico de alteração de regra, por exemplo, sai com o fuso de Brasília explícito no próprio valor. Isso teve um problema real: a primeira versão convertia certo mas devolvia um valor sem fuso embutido, e num servidor em horário universal o horário saía com três horas de diferença. O horário do histórico é sempre o de Brasília.

As exportações. Colunas de data e hora exigem a conversão para o fuso do negócio; data pura sai sem fuso. E os valores de lista nas colunas exportadas saem com o mesmo texto que o painel mostra ao operador, nunca com o nome interno.

O idioma não muda o fuso nem o formato. Quem usa o sistema em espanhol ou inglês vê as mesmas datas e horários de Brasília; o idioma muda o texto, não o relógio.

Tudo no sistema funciona pelo horário de Brasília, independentemente de onde o participante ou o operador está.

Para o cliente, isso significa três garantias que vale enunciar:

• a compra feita no último dia da campanha, mesmo à noite, vale. O dia da compra é contado pelo calendário de Brasília;
• os limites por dia renovam à meia-noite de Brasília, não antes nem depois;
• os horários nas telas, no histórico e nos relatórios são todos horário de Brasília. O cliente não precisa converter nada.

A conversa que mais aparece é com participante de outro fuso — Acre, por exemplo — que cadastra perto da meia-noite local e vê a cota do dia já contada, ou não contada, de forma que não bate com o relógio dele. A explicação é essa: a promoção corre pelo horário de Brasília, como está no regulamento.

• Falha: o participante diz que o limite de notas do dia não renovou.
• Possivel causa: a cota renova à meia-noite de Brasília. Se o participante está em outro fuso, o relógio dele ainda não virou pelo horário de Brasília, ou já virou antes.
• Como orientar: explique que a promoção corre pelo horário de Brasília. Oriente a tentar de novo depois da meia-noite de Brasília.
• Quando escalar: se já passou da meia-noite de Brasília e a cota não renovou, abrir issue no Jira (projeto DEV) com as evidências e o horário exato da tentativa.

• Falha: a nota de uma compra feita no último dia da campanha foi recusada por data.
• Possivel causa: a comparação é por dia de calendário no fuso de Brasília, e compra no último dia à noite deveria valer. Pode ser que a data informada seja de outro dia.
• Como orientar: confira a data da compra na nota contra o período da campanha. Confira também se a data informada no cadastro corresponde à nota.
• Quando escalar: se a data da compra estiver dentro do período pelo calendário de Brasília e a recusa continuar, acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o horário mostrado no histórico de alteração da regra não bate com o horário em que a alteração foi feita.
• Possivel causa: o histórico sai sempre no horário de Brasília, com o fuso explícito.
• Como orientar: compare com o horário de Brasília, não com o fuso local de quem alterou.
• Quando escalar: se a diferença for de horas inteiras e não se explicar pelo fuso de quem alterou, acionar o time de desenvolvimento urgentemente e abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o participante aniversariante foi recusado pela idade mínima no dia do aniversário dele.
• Possivel causa: a idade é calculada pelo dia de Brasília. Se ele tentou antes da meia-noite de Brasília, ainda não era o dia do aniversário para o sistema.
• Como orientar: oriente a tentar de novo depois da meia-noite de Brasília.
• Quando escalar: se já for o dia do aniversário pelo calendário de Brasília e a recusa continuar, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: o operador alterou a regra de uma campanha que ele considera encerrada e o sistema exigiu o papel Master.
• Possivel causa: a campanha ainda está dentro do período pelo dia de Brasília. Encerrada é o dia de fim anterior ao dia de hoje.
• Como orientar: confira a data de fim da campanha. No último dia ela ainda está em andamento, e a exigência de Master vale.
• Quando escalar: não é falha.

• Falha: um número gerado no dia do concurso ficou fora do sorteio pela Loteria Federal.
• Possivel causa: o prêmio não tem data de sorteio, e o corte usado foi o início do dia do concurso em Brasília. Números gerados depois disso não concorrem.
• Como orientar: confira a data de sorteio do prêmio e a data do concurso informada. A tela da apuração mostra até quando os números foram considerados.
• Quando escalar: se o número tiver sido gerado antes do corte mostrado e ainda assim não concorrer, abrir issue no Jira (projeto DEV) com as evidências.

• Falha: os totais de um relatório por período não batem com a contagem do cliente.
• Possivel causa: o recorte do período é feito pelo dia de Brasília. Uma contagem feita pelo horário universal divide os dias em outro ponto.
• Como orientar: confirme que a contagem do cliente usa o dia de Brasília. Os relatórios exportam data e hora já convertidas.
• Quando escalar: se as duas contagens usarem o dia de Brasília e divergirem, abrir issue no Jira (projeto DEV) com as evidências e o recorte usado.