A automação rodou na hora certa. O relatório trouxe o dia certo?
Separe horário de execução, calendário da fonte e data de negócio antes de aceitar o relatório.
O relatório chega às nove da segunda-feira em Xangai. O título diz “ontem”, mas os números vêm de um domingo que ainda não terminou em Los Angeles. A gestão pensa que compara dois dias completos; um deles está em andamento.
Pontualidade não comprova uma janela de dados completa. O fuso da automação de IA define quando a execução começa. Não define o encerramento do dia na fonte nem a data de negócio do relatório.
No Buda, Skills definem como; Automations definem quando. Inclua a regra de calendário no método antes de discutir o agendamento.
Dê nome a três relógios
- Relógio de execução: fuso IANA e horário local, como segunda às 09:00 em
Asia/Shanghai. - Calendário da fonte: o fuso que delimita o dia dos dados, como meia-noite a meia-noite em
America/Los_Angeles. - Data de negócio do relatório: o dia em que a equipe o arquiva e o intervalo real que pretende comparar.
A data de negócio não é o instante da consulta nem outro nome para a data da fonte. Um briefing de segunda em Xangai pode usar dados completos do sábado de Los Angeles, desde que informe esse corte. Trocar o título não transforma sábado em domingo.
Às nove, o domingo da fonte ainda está aberto
O exemplo é fictício, com conversão real de fusos IANA. Não é registro de execução do Buda nem afirmação sobre atraso de publicação de algum fornecedor.
Segunda, 19 de outubro de 2026, 09:00 em Xangai corresponde a domingo, 18 de outubro, 18:00 em Los Angeles. Faltam seis horas para o domingo terminar. O encerramento ocorre às 15:00 de segunda em Xangai.
| Xangai | Los Angeles | O que sabemos sobre domingo? |
|---|---|---|
| 19 de outubro, 09:00 | 18 de outubro, 18:00 PDT | O dia ainda não terminou |
| 19 de outubro, 15:00 | 19 de outubro, 00:00 PDT | O calendário fechou; a ingestão pode estar incompleta |
| Após confirmação da fonte | Conferir o estado real | Aceitar completude apenas com evidência |
Use o intervalo semiaberto [2026-10-18 00:00, 2026-10-19 00:00) em America/Los_Angeles. Em Xangai, equivale a [18 de outubro 15:00, 19 de outubro 15:00). Isso evita ambiguidades sobre frações de segundo depois de 23:59:59.
O “ontem” de calendário em Xangai vai de 18 de outubro 00:00 a 19 de outubro 00:00. As 24 horas móveis antes das 09:00 de segunda vão de domingo 09:00 a segunda 09:00. São três janelas diferentes. Mostre intervalo e fuso, não apenas “ontem”.
Entregue um contrato de calendário por execução
“Analise ontem às nove” deixa decisões importantes em aberto. Registre no pedido ou no Skill os campos abaixo. É um contrato proposto, não um bloqueio nativo ou uma garantia automática do Buda.
Data de negócio: 2026-10-19, Asia/Shanghai
Início planejado: 09:00, Asia/Shanghai
Fonte: dados operacionais autorizados de Los Angeles
Data da fonte: 2026-10-18, America/Los_Angeles
Intervalo: [10-18 00:00, 10-19 00:00)
Comparação: dia anterior completo na mesma definição
Data-through: última data realmente retornada pela fonte
Completude: confirmada; null se desconhecida, não zero
Disponibilidade mais cedo: após 15:00 de Xangai;
confirmar atraso de ingestão
Chave: ID da fonte + data da fonte + tipo + versão
Pendências: atraso, revisões, responsável por esperar/partial
A chave ajuda a localizar trabalho existente. Não é trava de execução única. Se houver revisão, preserve versão anterior e relação de substituição. Separe atualização da fonte, corte dos dados e geração do relatório, em vez de reuni-los em um updatedAt.
Em dados de eventos, confirme se o filtro usa ocorrência ou importação. Conversão de fuso não resolve eventos atrasados ou correções retroativas. Um dia encerrado ainda pode mudar.
Um dia incompleto pede uma saída honesta
No exemplo fictício de segunda às 09:00, a pessoa responsável escolhe entre dois resultados:
- Esperar a data solicitada. Informar que 18 de outubro em Los Angeles termina às 15:00 de Xangai e que a conclusão da ingestão é desconhecida. É uma atualização de estado, não um relatório completo de domingo.
- Entregar parcial. Se dados completos até sábado foram realmente verificados, indicar data de negócio 19 de outubro e corte da fonte em 17 de outubro, Los Angeles. Marcar domingo incompleto e não calcular variação diária com janelas incompatíveis. Sem dia completo verificado, não oferecer um número substituto.
Decidir esperar não significa que o sistema pausa, tenta novamente ou altera o horário automaticamente. Uma execução posterior exige definição e autorização próprias. O método precisa primeiro expressar o estado correto.
Horário de verão muda o deslocamento, não o significado
Na segunda, 2 de novembro de 2026, 09:00 de Xangai equivale a domingo 17:00 em Los Angeles, agora PST. O domingo termina às 16:00 em Xangai, não às 15:00 do exemplo de outubro.
Mantenha America/Los_Angeles e converta a data específica. Não fixe “subtrair quinze horas”: os exemplos têm diferenças de quinze e dezesseis horas. A execução em Xangai continua às 09:00; muda a correspondência entre os locais.
Horários de madrugada numa região com horário de verão podem não existir ou ocorrer duas vezes. Confirme o tratamento do agendador em datas concretas antes de prometer uma execução por intervalo de negócio.
Confira três entradas sem criar um agendamento
| Verificação proposta | Estado | Saída esperada |
|---|---|---|
| Normal | Dia encerrado e completude confirmada | Data de negócio, intervalo, corte e janela anterior comparável |
| Atraso | Dia fechado, mas fonte não confirmada ou parcial | Espera/partial e lacuna; desconhecido não vira zero |
| Repetição | Chave existente ou envio anterior desconhecido | Localizar versão e estado; pedir decisão antes de reenviar |
São pedidos de aceite ainda não executados. Preserve entrada, resultado real e decisão. Um arquivo existente não comprova envio: a repetição precisa consultar o estado real.
Perguntas de calendário
A fonte tem datas, mas não informa fuso. Podemos inferir?
Não. O limite decide quais eventos entram. Pergunte ao responsável pelo fuso e pela completude. Marque o desconhecido e interrompa a comparação entre dias; não use automaticamente o fuso do navegador ou do operador.
Por que um dia encerrado não basta?
Calendário e ingestão são condições diferentes. Confira data-through, cobertura e política de atrasos. Se só souber que o dia acabou, completude permanece desconhecida.
Um novo processamento no dia seguinte muda o arquivo de negócio?
Mantenha data e intervalo originais. Registre separadamente horário da nova tentativa e versão. Se o envio estiver incerto, confira antes de repetir, mesmo quando a geração funcionar.
Faça uma amostra explicar as datas primeiro
Entregue ao Buda Agent os três relógios confirmados e as condições de parada. Peça uma declaração de datas e pendências, sem criar automação ou enviar mensagens. Na aba Agent, confira entradas e arquivo real.
Se o trabalho se repetir, pesquise e instale um Skill adequado no Marketplace do Buda AI e confira seus campos de calendário. O pedido de relatório em uma frase simplifica a entrada, mas não define o significado de “ontem” para a equipe.