4. 节假日体系

在清算结算日历的构建中，节假日体系是最基础、也最容易被低估的一层。很多系统故障并非源于算法错误，而是因为对“今天到底算不算工作日”的判断出现了偏差。要建立可靠的日历引擎，首先必须把节假日的类型分清楚，因为不同类型的节假日，其影响范围、生效方式、可预测性和处理策略完全不同。

一、核心原理：五类节假日的本质差异

节假日体系可以按“是否可提前预知”和“影响范围”两个维度来划分。法定节假日和周末是规则明确、可提前数年推算的；调休虽然也由官方发布，但每年不同，需要外部数据同步；临时休市和特殊事件休市则属于突发性事件，无法提前写入静态日历。

• 法定节假日：由国家或地区法律规定的休息日，如元旦、春节、国庆节。影响范围通常是全市场、全业务线，包括银行、交易所、清算所同步休市。
• 周末：每周六、周日。影响范围是常规性的，但需注意部分市场周末仍可进行某些后台操作或跨境交易。
• 调休：为形成连续假期，将某个周末调整为工作日，或将工作日调整为休息日。影响范围是“名义工作日”与“实际工作日”发生偏移，最容易导致日历判断错误。
• 临时休市：因极端天气、技术故障、公共事件等临时宣布的休市。影响范围通常是局部市场或特定品种，具有突发性和短时效性。
• 特殊事件休市：如国丧、重大庆典、疫情管控等，影响范围可能覆盖多个市场，持续时间从半天到数周不等。

二、方法流程：分层日历的构建与更新

建议采用“三层日历模型”来管理节假日体系。第一层是基础日历，由周末和法定节假日构成，可按年预生成；第二层是修正日历，记录调休安排，每年由官方发布后导入；第三层是事件日历，记录临时休市和特殊事件休市，通过消息总线或人工录入实时更新。

calendar_layers:
  base:
    - weekend: [SAT, SUN]
    - holidays: [2025-01-01, 2025-01-28, 2025-01-29, ...]
  adjustment:
    - workday_override: [2025-01-26, 2025-02-08]
    - holiday_override: [2025-02-03, 2025-02-04]
  event:
    - market: SSE
      date: 2025-07-15
      type: TEMPORARY_CLOSE
      reason: TYPHOON
      scope: [EQUITY, BOND]

判断某一天是否为工作日时，优先级应为：事件日历 > 修正日历 > 基础日历。也就是说，如果事件日历中标记了临时休市，即使基础日历显示是工作日，也应判定为休市。

三、影响范围对比

四、案例与场景：调休引发的清算日错位

某年春节前，交易所发布调休通知：1月26日（周日）调整为工作日，2月3日（周一）调整为休息日。某清算系统的日历表只更新了法定节假日，未同步调休信息。结果1月26日系统判定为休市，未生成清算任务；而2月3日系统判定为工作日，实际市场休市，导致清算指令空跑并触发对账异常。

另一个典型场景是临时休市。某年台风导致某交易所临时休市半天，但银行间市场仍正常运营。如果清算系统采用“一刀切”的休市判断，就会错误地停止所有清算通道。正确的做法是按市场、按品种分别维护休市状态，并在事件结束后及时恢复。

五、常见误区与检查清单

• 误区一：把调休当作法定节假日处理，只增加休息日，忽略周末变工作日。
• 误区二：临时休市只通知前台交易，未同步到后台清算日历。
• 误区三：跨境业务中，只考虑本地节假日，忽略对方市场休市。
• 误区四：事件日历没有过期机制，导致历史临时休市长期残留。