旧的一次预约为何还在：Skedda的周期系列先看最后结束时间

日程上还有一条早已结束的活动室预约，是否就说明保留期设置没有生效？Skedda的Booking and Visit Data Retention帮助页列出不止一种原因，其中一项专门针对周期预约：系统看的是系列最后一次发生的结束时间，而不是只看眼前这条较早记录。[2] 理解旧记录为何仍在，需要先辨认这项数据关系。

原文说明，重复预约要等到最后一次发生的结束时间已经早于保留期范围，才满足删除条件。因此，同一系列中较早的发生可能仍显示在日程上，因为系列还有较晚的发生处于保留期内。[2] 一条记录过去多久，与整个系列的末次已经过去多久，可能得到不同答案；前者不能直接代替后者。

可以用明确自拟的日期关系解释。假设一组周期预约同时包含较早的春季日期和较晚的秋季日期，当资料整理者只看到春季那条时，还不知道整组最后一次何时结束。即使这条春季记录单看已经较旧，也不能据此认定整个系列都满足了原页的删除条件。这个例子没有指定账号的真实保留天数，也没有查询或创建任何预约。

另一种原因是清理过程本身。帮助页的问答说，旧预约和访问记录是分小批次删除的，后台清理任务仅周期运行。调整保留期后，系统可能需要一些天来追上新设置；文档还写到，处理删除可能用到最长三十小时。[2] 这是原厂对异步处理的说明，不是本文对某条真实预约的计时测试，也不能被改写成所有旧记录都会在同一时刻消失。

这两种解释不能混成一句“系统还没来得及删”。系列末次条件解释的是对象是否已符合那项条件，分批处理解释的是满足条件后仍可能存在处理时差。只凭“日期很早但还看得到”这一现象，无法确认究竟是哪一种；本文也不据此诊断某个账号故障。保留原文区分，比为所有迟迟可见的记录统一指定原因更准确。

另一个需要辨明的对象是过去与未来。原页明确说，数据保留设置针对过去的预约；能提前多远预约未来时段，是booking window规则的问题。[2] 因而，旧资料保存得久，不会由这段说明自动推出未来排期也更远。Repeat Bookings页面还说明，改动一次发生会使它与系列分离为独立单次预约。[1] 这个细节在此仅提醒：不能凭日期相似，就认定两条记录仍属于同一系列。

两份所读页面均显示2025年3月4日，首次发布日期未知。本文将重点限定为周期系列的保留参照与分批清理机制，不提供删除、修改或导出操作，也不建议组织设定任何法定保留年限。资料说明能支持理解文档中的条件，却不能代替真实账号状态、场馆空位或个人预约权益的核实。