“每天九点发一次”还不是完整的机器人需求。九点属于哪个城市？用户旅行后是否改变？当天停机，恢复时还发不发？这些选择决定通知是否符合预期，不能留给服务器默认时间。
一份 Daily Update Telegram Bot 客户委托要求每日预定时间发送文字和图片，并保存发送记录、在停机后恢复。2026 年 11 月 3 日核查时页面显示开放，但绝对发布日期未知，不能依据动态相对时间判断它刚发布。它提供问题背景，不是 BitBear 已交付案例。下面的时间政策是本文提出的设计示例，不是客户原话或现成产品功能。
先区分三种时间承诺
- 一次性时刻：例如某一天北京时间九点。确认后可保存明确的 UTC 时刻，同时保留原输入与时区供展示。
- 每天当地九点：按指定地区的日历重新计算下一次执行；遇到夏令时变化，相邻执行不一定相隔 24 小时。
- 每隔 24 小时：从确定起点按固定时长前进；跨越时钟调整后，当地显示时间可能变化。
只有第一种适合仅靠一个 UTC 时间戳表达全部意图。重复计划还应保留时区、当地时间、重复规则和生效范围。保存“下一次执行时间”方便调度，但不能用它取代业务规则。
例如，固定地区九点的日报，不应每发送一次就简单加 86400 秒。用户要的是日历上的九点；固定时长轮询则可能确实需要间隔 24 小时。两者都可以合理，关键是确认时展示清楚。
保存地区时区，不用语言猜时区
IANA 时区数据库维护地区时间与规则变化。对于随地区时间运行的计划，建议保存 America/New_York 或 Asia/Shanghai 这类标识，而不是只存今天的 UTC 偏移。UTC-5 不能表达一个地区未来所有夏令时变化；“北京时间”也不应由界面中文自动推断。
创建计划时让用户确认地区。确认卡至少显示：当地日期时间、地区时区、下一次 UTC 时刻、重复方式。用户改个人资料中的时区时，先询问已有计划是保持原地区九点，还是改为新地区九点。不要因一次语言切换或旅行就批量移动已确认通知。
时区数据需要更新。若部署环境没有可用的数据或不认识指定标识，应拒绝确认并解释原因，不能悄悄回退到服务器时区。
夏令时与月底都需要明确政策
调表时某些当地时间会不存在，另一些会出现两次。例如计划中的凌晨时间可能落入这一窗口。让实现方说明如何处理：跳过、顺延到有效时刻，或要求用户改选；重复出现的时间选第一次还是第二次。确认页应展示最终选定结果，不能靠一次正常日期测试通过就认为全年正确。
RFC 5545区分 UTC、带时区的当地时间和浮动时间，并规定了 iCalendar 的日期与重复规则。采用 iCalendar 语义时，应按相应条款处理；自定义提醒的业务政策要另行命名。 不能把自选的“顺延”说成所有日历库的默认行为。
月底也是同类问题。“每月 31 日”可以约定没有 31 日的月份不发送；“每月最后一天”则是另一条规则。RFC 5545 的重复规则会忽略生成的无效日期，不意味着自动改到月底。若客户选择月底发送，就应明确写成月底规则，并测试二月与闰年。
漏发与改时间不能产生意外补发
以下是一套可讨论的日报政策示例：
- 为每个计划和每次预定时刻分配独立执行记录，保留预定时间与实际处理时间。
- 恢复后，超过约定宽限期的旧日报标为错过，不一次补发数天内容；宽限期内是否补发由业务确认。
- 修改或取消计划时增加版本。尚未发送的旧版本执行，开始前重新检查是否仍有效。
- 修改后的首次执行必须展示给管理员确认，不把过去的九点自动解释成“现在立即补发”。
这些是建议的产品规则，并不证明某个调度平台原生支持它们。发送记录还要区分计划触发、发送接口接受与用户阅读，不能把日志写入就当成已读回执。收件人重试与限流另见群发指南，本文关注的是“哪一次应当发生”。
BotFatherV2 可以从哪里开始，哪里需要定制
截至 2026 年 11 月 3 日，BotFatherV2支持 AI 对话创建和修改 Telegram Serverless 机器人、导入已有 Serverless 机器人、发布版本及保留当前业务数据的代码回滚。
AI 开发文档列出的首版范围包括菜单、简单社群助手、投票和按用户隔离的持久化工具；固定 SDK 不支持任意 npm 模块或 Node/Bun API，也不新增依赖付费 AI 的运行能力。公开文档没有为本文完整定时推送方案提供能力保证。
因此可以先描述一个按命令新增、查看、取消计划记录的原型，核验字段、隔离和日期处理是否受支持。保存时间、手动查询到期记录，不等于机器人能在无人发消息时主动醒来。 自动触发器、时区数据、可靠恢复、图片发送及外部调度接入必须分别验证；不能假定安装一个 npm 调度包即可解决。
若必须按原委托交付 VPS、Python/Node 源码和完整自动推送，应按独立定制项目评估；现有 Serverless 机器人不能直接等同该技术栈。仅需少量人工安排时，可以先评估客户端现有功能；需要订阅、日志和业务控制时再评估完整机器人。BotFatherV2 与 Telegram 官方 BotFather 无隶属关系。
可交给 AI 或外包方的需求模板
先设计一个每日通知计划原型。管理员明确选择地区时区及当地发送时间；保存原规则，不用服务器默认时区或界面语言推断。确认时展示下一次当地时间和 UTC 时间。地区变更不得自动修改旧计划。请先说明当前环境是否支持时区计算、无人交互的自动触发、持久执行记录与取消旧版本；不支持时只做按命令管理和查看记录，明确不提供定时发送。若另行实现自动推送，先确认夏令时歧义政策、漏发宽限期与补发规则，再展示测试结果；图片、外部表格和 VPS 部署分别列入范围。
这份模板有意要求先列出缺口，不承诺价格、开发周期或未经验证的运行能力。
验收要跨越时间边界
- 对比“每天当地九点”与“每隔 24 小时”，确认两种规则没有混用。
- 用观察夏令时的地区测试切换前后日期，并验证缺失与重复时间政策。
- 测试每月 31 日、月底、二月与闰年，不把不同规则默默合并。
- 修改用户时区后，原计划按已确认政策保持或迁移；其他用户的计划不变。
- 在到期前取消、修改或重启，旧版本不会继续发送；错过的执行按约定处理。
- 在完全没有新聊天消息时验证真正的定时执行；只测试手动命令不能验收主动推送。
- 将预定时间、实际时间、时区和执行状态与独立参考时间逐项核对。
来源与核查
- Freelancer，英文客户项目 Daily Update Telegram Bot，项目 40189576；发布日期未知，2026-11-03 页面显示 Open，仅概括客户正文。
- IANA，Time Zones，持续维护、无单一发布日期；2026-11-03 核查。用于时区规则依据。
- B. Desruisseaux / IETF，RFC 5545: iCalendar，2009 年 9 月；2026-11-03 核查第 3.3.5、3.3.10 和 3.8.5.3 节。用于时间表示与日历重复语义，不证明 BotFatherV2 实现该标准。
- BitBear Studio，产品主页及 AI 开发文档，2026-11-03 核查。英文指定入口
/en-US本次不可访问，英文能力说明通过可访问的/en与/en/docs/ai-development核对。