群里约好下周六九点见，日历也填了九点，为什么有人还是早到一小时？最容易想到的解释是忘了时差。可有一种更隐蔽的情况：两个人第一次都准时到了，第二次也都照着自己保存的重复规则执行，却没有在同一刻出现。出错的地方，藏在“每周还是这个时间”里面。
同样写着九点，可以表达三种不同的约定：某一场活动发生的确定时刻、每周在某座城市钟表上的九点，或者无论人走到哪里都按当地九点做一件事。它们在某一天可以碰巧重合，但不能因此互相替代。让 AI 整理日程之前，先分清自己究竟想保留哪一种不变。
第一场对上了，不代表重复规则也对了。拿一个虚构的跨城线上拼贴会举例：发起人在伦敦，希望连续两个周六上午九点展示作品，北京的朋友同时参加，日期是 2026 年 10 月 24 日和 31 日。10 月 24 日的伦敦九点，对应 UTC 八点、北京时间十六点，三种写法指向同一场活动。
到了 10 月 31 日，如果坚持伦敦钟表仍然显示九点，对应的 UTC 变成九点，北京时间也随之变成十七点。伦敦发起人保持了自己的上午安排，北京参与者的钟面时间则比上周晚一小时。这不是任何人迟到，而是双方原本选择了以伦敦的当地时间为准。
另一种做法，是记住首场的 UTC 八点，向后加足七个二十四小时。这样第二场仍是 UTC 八点、北京时间十六点，但伦敦已经显示八点。北京的钟面没有变，伦敦发起人却要提前一小时开始。计算上完全一致，只是保留的东西不同。
分歧就发生在复制规则的时候。第一份约定保留“伦敦周六九点”，第二份保留“距离上一次经过一百六十八小时”。在这组日期里，前者两场相隔一百六十九小时，后者相隔一百六十八小时。不是算法差了一小时，而是输入的约定本来就不相同。
这也解释了为什么只核对第一条日程不够。第一次创建时，两种规则会得到完全相同的三个城市时间，无论截图多清楚，都看不出下一次将沿着哪条规则展开。需要展开第二次发生时间，才能看见这份重复安排到底跟着钟面走，还是跟着固定时长走。
换算与复制的先后顺序也很关键。先列出两天各自的伦敦九点，再逐行换算，会得到北京的十六点和十七点；先把第一场换成北京十六点，再复制这个数字，则把北京钟面固定了下来。把第一行的换算结果当成后续模板，正是这种误差最自然的来源。
时区不是一个永远固定的加减数。“伦敦当前比 UTC 快一小时”描述的是某个日期的偏移；“按照伦敦时区安排”则需要在目标日期查对应规则。只把今天的加一小时记下来，再用到下周，就丢掉了日期这一条件。城市名称负责选规则，日期负责确定那天应用哪一种偏移。只写“九点”缺少地点，只写“伦敦九点”却不写日期，也不能完整确定一次活动。把日期、当地钟面时间和所依据的时区一起交给日历或 AI，才给了换算所需的材料。
如果双方都要求自己的钟面永远不变，就要先承认这可能是两个无法同时满足的条件。在上面第二周，伦敦九点与北京十六点已经不指向同一刻，换一个日历工具也不能把它们变成同时。大家需要重新商量以哪边为准，或者给转换后的那一场单独改约。工具负责表示约定，无法替一份相互冲突的约定消除冲突。
有时同一天的一个钟点，也会出现两次。把演示缩小到 10 月 25 日：按同一份时区数据，伦敦当地 01:30 有两个对应的时刻，一个是 UTC 00:30，另一个是 UTC 01:30；换到北京，分别为 08:30 和 09:30。纸面上的日期与小时分钟一样，时间线上的位置却相隔一小时。钟表读数不总能独自充当唯一标识，遇到重复的当地钟点，表达还需要明确采用哪一次，或者直接确认它对应的 UTC 时刻。
让 AI 帮忙排日程，先让它展开两次给你看。与其让 AI“帮我换算时差并每周重复”，不如说明谁的钟面时间需要固定。直接能用的写法是：
请整理两次线上拼贴交流，日期为 2026 年 10 月 24 日与 31 日，均以 Europe/London 当地 09:00 为准。分别列出 UTC 和北京时间，说明两次实际相隔多少小时。只生成供核对的安排表；不要把“每周当地同一时刻”改成固定间隔，也不要创建或发送邀请。
拿到回答后，先看表的第二行，再看解释是否一致：第二场应当保持伦敦九点，北京时间会变成十七点。若结果把两地钟面都固定住，就需要回查它采用了什么规则，而不能因为表格整齐就直接接受。
核对完成以后，再把约定保存成日历活动。检查的重点也很具体：活动详情中的时区有没有选对，重复实例是否符合要固定的当地时间，参与者看到的是不是同一场活动。若应用提供预览未来实例，就挑一次规则变化前后的日期比较；找不到相关设置时，先保留明确的两次日期也可以。
还有一个容易混在一起的动作：换显示时区和改活动时间。前者只是换一种钟面查看同一时刻，后者可能真的移动了活动。出门旅行后，如果看到原来的九点显示成别的小时，不要立刻把数字改回九，先确认自己只是换了所在地，还是也想重新约定大家碰面的时刻。
清楚的时间约定，能让人把注意力留给活动本身。线上拼贴会需要的不是一张复杂的世界时钟，而是一句所有人理解一致的话：究竟让谁的当地九点保持不变。你下一次复制重复日程时，可以先展开第二次，看看自己保存的那个“还是九点”，到底跟着什么走。
相关资料：Python：zoneinfo — IANA time zone support；RFC 5545：iCalendar（3.3.5、3.8.5.3）