周一早上九点，日报准时到了。标题写着“昨日业绩”，数字却来自还没结束的洛杉矶周日。运营主管以为在比较两个完整日，实际比较的是一天和半天。
准点启动与数据完整，是两件事。 AI automation timezone 的配置只回答任务何时运行；它不会替你决定上游的一天何时结束、报告该归哪一天。
在 Buda 中，Skills 定义方法，Automations 定义运行时机。把日期判断写进方法，再讨论排期，才能避免任务守时、结论失真。
先给三个时钟各自命名
- 调度时钟： 任务在哪个 IANA 时区、几点启动，例如
Asia/Shanghai的周一09:00。 - 来源日历： 数据提供方按哪个时区划分日期，例如
America/Los_Angeles的00:00至次日00:00。 - 报告业务日： 团队把这份报告归到哪天，以及报告实际要比较的哪段数据。
报告日期不是读取日期，也不是来源日期的别名。同一份上海周一的经营简报，可以合法使用洛杉矶周六的完整数据，但必须直接写清截止日。不能改一个标题就把它变成周日业绩。
同一个九点，来源日还没结束
以下是虚构的内部日报场景，使用真实 IANA 时区换算；不是某次 Buda 运行记录，也不声称上游具有固定发布延迟。
2026年10月19日，周一，上海09:00，对应洛杉矶10月18日周日18:00。洛杉矶的周日还剩六小时。它要到上海周一15:00才结束。
| 上海时间 | 洛杉矶时间 | 能对周日数据作什么判断 |
|---|---|---|
| 10月19日09:00 | 10月18日18:00，PDT | 日历尚未闭合，不能标完整 |
| 10月19日15:00 | 10月19日00:00，PDT | 周日结束，但不代表来源已完成入库 |
| 来源明确确认完成之后 | 以来源实际状态为准 | 才能接受该来源日完整性 |
来源周日的范围应写为半开区间 [2026-10-18 00:00, 2026-10-19 00:00)，时区是 America/Los_Angeles；换成上海时间是 [10月18日15:00, 10月19日15:00)。这样没有“23:59:59是否含最后一秒”的歧义。
上海的“日历昨日”则是10月18日00:00至19日00:00。周一09:00往前滚动24小时是10月18日09:00至19日09:00。这三段区间都不一样。 标成“昨天”会掩盖差异，表格应该带区间与时区。
给每次运行一张日历契约
不要只写“每天九点分析昨天”。在任务输入或Skill方法中，记录以下字段。它们是一份建议的数据契约，不是Buda自动生成的系统锁或完整性保证。
报告业务日：2026-10-19（Asia/Shanghai）
计划启动：09:00（Asia/Shanghai）
来源：已授权的洛杉矶运营数据
来源日：2026-10-18（America/Los_Angeles）
来源范围：[10-18 00:00, 10-19 00:00)
期望比较：前一个同口径完整来源日
data-through：来源实际返回的最新数据日期，不按读取时刻填写
完整度：来源确认；未知则为null，不是0或complete
最早可用：不早于上海15:00；入库延迟另向来源确认
业务键：来源ID + 来源日期 + 报告类型 + 版本
待确认：发布延迟、修订规则、谁决定等待或partial
业务键用于找到已有产物，不等于原生幂等锁。若同一业务日需要修订，就保留旧版本并记录版本关系。来源最后更新日期、覆盖截止时间与报告生成时间分别保存，不混成一个 updatedAt。
如果来源按事件时间记账，还需确认日期过滤的是事件时间还是导入时间。时区换算解决不了迟到事件和后补数据：来源日已经结束，数据仍可能被修订。
源日没闭合，不要硬凑一个完整日报
在虚构的周一09:00例子里，可选择两种明确交付，具体由负责人决定：
- 等待该来源日。 输出“洛杉矶10月18日尚未结束，最早日历闭合为上海15:00；入库完成时间待来源确认”。这是状态说明，不是假装拿到了周日完整结果。
- 交付partial。 如果确实已有截至洛杉矶周六的完整数据，就写“报告业务日10月19日；本次数据截至洛杉矶10月17日；周日未完成”。不可比区间不计算日环比。没有经过核验的完整日，就不补一个数。
决定等待不等于系统会自动暂停、自动重试或改排期。想增加后续运行，需要单独确定授权与执行方式。当前方法只负责输出清楚的状态。
夏令时改变的是偏移，不是业务含义
2026年11月2日，上海周一09:00，对应洛杉矶周日17:00，已经是PST。洛杉矶周日闭合改为上海周一16:00，而不是十月的15:00。
保留 America/Los_Angeles，每次按具体日期换算；不要把“北京时间减15小时”写成永久规则。上例十月差15小时，十一月差16小时。上海的09:00调度仍是09:00，变的是两地对应时刻。
若任务排在实行夏令时地区的本地凌晨，某些日期会出现不存在或重复的本地时刻。先明确调度器对这些情况的处理，并用具体日期检查；不知道其行为就不要承诺每次恰好运行一次。
用三种输入检查方法，而不是立即建任务
| 建议检查 | 输入状态 | 期望输出 |
|---|---|---|
| 正常 | 来源日已闭合，来源确认完整 | 明示业务日、来源区间、截止日和可比前窗 |
| 延迟 | 日历闭合但来源未确认，或仍缺一部分 | 等待/partial及具体缺口；不把未知写成0 |
| 重复 | 同业务键已有产物，或上次发送状态未知 | 找到已有版本；核清状态后再由人决定，不盲重发 |
这些是未执行的验收请求，不是已通过的测试。保留输入、实际输出和负责人结论。重复运行检查需要实际读取状态；如果文件存在但无法确认是否发送，文件本身不能证明发送成功。
日期口径常见问题
来源只有日期，没有时区，能先猜一个吗？
不能。日期边界决定哪些事件被纳入。先向来源负责人确认时区和完整度定义；报告标明来源时区未知，并暂停跨日比较。不要按浏览器或当前操作者的时区替它填空。
来源日结束了，为什么仍不能说完整？
日历闭合是必要条件，来源完成是另一条件。核对data-through、实际覆盖及迟到数据规则。若只能知道日期已结束，完整度仍应保持未知。
报告第二天重跑，归档日期要改吗？
保持原报告业务日及来源区间，另外记录重跑时间与修订版本。否则一个业务日会被拆成多份看似新报告。重复发送状态未知时先查记录，不因重新生成成功就再发一次。
先让一份样例把日期说清楚
把已确认的三个时钟和停止条件交给 Buda Agent，要求先生成一份日期说明与待确认清单，不创建任务、不发消息。在Agent tab查看工具输入和实际文件，确认它没有把读取时间当数据截止日。
规则反复使用时，可以在 Buda AI 的 Marketplace 搜索并安装合适的Skill，检查它是否接受这些日期输入。一句话日报能简化执行入口，但跨地区的日历判断仍需先说清；格式自动化不会替团队定义“昨天”。