归档开云赛事赛程变更通知时，应同时保存原安排、新安排、变更发布时间、适用比赛身份和下一次复核节点。只把日历中的旧时间改成新时间，会丢失变化链条，也难以解释提醒为何冲突。可靠的归档不是复制一段通知，而是建立可以追溯的版本记录，让读者知道哪一项已确认、哪一项仍待更新。
先锁定比赛身份，避免改错记录
赛程中可能出现名称相似的队伍、不同年龄组、主客场互换或同一天多场比赛。归档前应使用赛事名称、赛季、轮次、对阵双方、原日期和场地共同识别一场比赛。若有公开比赛编号，可作为辅助字段，但不应仅凭标题相同就自动合并。名称拼写变化也要保留对照，避免把更正名称误当成新增比赛。
跨时区赛事尤其容易产生日期差异。通知写的是举办地当地时间，用户日历可能显示为越南时间或设备时区。归档应分别记录原始时区与换算后时间，并标明是否跨日。夏令时规则会随地区和日期变化，因此不能用固定小时差批量替换全部赛程。
- 身份字段：赛事、赛季、轮次、对阵与场地。
- 原版本：原日期、原时间、原时区和原状态。
- 新版本：新安排、发布时点、变更原因的有限描述。
- 待确认项：场地、入场安排、转播信息或后续轮次影响。
- 复核点：临近比赛、日历同步完成后和再次发布通知时。
建立版本链而不是覆盖旧值
每次变更应新增一条版本记录，至少包含记录时间、修改字段、旧值、新值与信息状态。若第二次通知撤销第一次改期，版本链可以清楚显示恢复过程。直接覆盖会使读者误以为当前安排从未变化，也无法排查重复提醒、缓存残留或不同页面显示不一致的问题。
状态词要使用清晰且有限的集合，例如计划、待确认、延期、取消、重新安排和已结束。不要把“讨论中”写成“已确定”，也不要依据社交讨论补全未公布的日期。变更原因若没有可靠说明，只记录为未说明即可；归档目标是准确传递已知事实，不是猜测组织方决定。
同步日历与页面时的检查顺序
先更新主记录，再更新日历订阅、分类列表和提醒任务，可以减少多个版本同时存在。更新后要查看本地时区显示、全天事件设置、重复事件和提醒次数。若外部日历有缓存，不要立即删除原记录后新建一个身份不同的事件，否则用户可能同时收到旧、新两组通知。更稳妥的方式是沿用稳定身份并更新字段。
- 冻结原通知文本或结构化字段，记录获取时间。
- 核对比赛身份与时区，确认要修改的唯一记录。
- 新增版本项，保留旧值，不直接抹除历史。
- 同步页面和日历，再检查重复项与跨日显示。
- 在设定的复核节点重新确认当前状态。
如果多个来源显示不同时间，应优先呈现冲突本身，并标记各自更新时间。不要为了让页面整齐而任选一个值。待信息一致后再关闭冲突状态，同时保留解决时间。这样既能降低误导，也方便后续分析信息延迟发生在哪个环节。
常见问题
旧赛程时间需要删除吗？
公开展示可突出当前安排，但归档中应保留旧值与变更时间。旧值有助于排查提醒冲突和解释版本变化。
通知没有写时区怎么办？
不要自行断言。可根据页面明确上下文标记暂定解释，同时保留“时区待确认”，并在下一复核点更新。
同一比赛多次改期如何处理？
为每次变化新增连续版本，记录旧值、新值和发布时间。最终页面显示当前版本，历史链仍应可追溯。