多时区聚合规则疑问：子区域数据应归属总部哪一日统计？

背景概述 #

我们的系统采用单父节点多子节点架构：总部位于韩国（时区标识Asia/Seoul），下设中东（Asia/Riyadh）、北美（America/New_York）等区域节点。系统每小时执行批处理作业，当目标时区当地时间为凌晨1点时，触发该时区前一日的数据清洗操作，核心逻辑代码如下：

@Cron(CronExpression.EVERY_HOUR, { name: 'hourlyUlsRefineJob' })
async hourlyUlsRefine() {
  this.logger.log('Started hourly ULS aggregation job.');

  const nowUtc = dayjs.utc();
  const availableTimezones = Object.values(DivisionTimezoneType); 

  for (const timezone of availableTimezones) {
    const localTime = nowUtc.tz(timezone);

    if (localTime.hour() === this.BATCH_TARGET_HOUR) {
      this.logger.debug(`It's ${this.BATCH_TARGET_HOUR}:00 AM in ${timezone}. Triggering ULS batch process.`);
      await this.orchestrateCusForTimezone(timezone);
    }
  }
  this.logger.debug('Hourly ULS aggregation job check finished.');
}

核心疑问 #

各区域的数据清洗流程运行正常，但总部汇总时遇到日期归属矛盾：

• 韩国标准时间（KST）8月26日（自然日）对应UTC时间范围为8月25日15:00至8月26日14:59
• 阿拉伯标准时间（AST）8月25日（自然日）对应UTC时间范围为8月25日21:00至8月26日20:59

此时AST的8月25日统计数据，从总部KST视角看，覆盖了KST的8月26日06:00至8月27日05:59，倾向归属总部8月27日统计；但从UTC日期维度看，该数据横跨UTC8月25日至26日，又有归属总部8月26日的依据，需明确行业通用标准。

行业标准及建议 #

1. 优先对齐总部业务时区（主流方案） #

跨国企业数据汇总的通用原则是以业务决策核心（总部）的时区为基准，所有区域数据的归属统一对齐总部的自然日周期，原因如下：

• 确保管理层查看数据时，符合本地业务运营的时间认知，比如总部每日早会查看的“昨日报表”，对应总部时区的完整自然日经营数据。
• 避免因UTC或其他区域时区导致业务数据与本地经营节奏脱节，减少数据解读的歧义。

以本次场景为例：AST8月25日的业务数据结束时间为AST8月25日23:59（对应KST8月26日06:59），该时间点落在总部KST的8月26日，因此应将整份AST8月25日数据归属到总部8月26日的统计报表中。若需更精细化拆分，可将数据按UTC时间切割为KST8月26日和8月27日的两个部分分别归属，但多数企业为简化流程，会按区域业务日对应的总部时区结束日期统一归属。

2. 明确规则的可追溯性 #

无论最终选择哪种方案，必须在系统文档、业务规范中明确标注数据归属规则，确保技术团队、业务团队对规则的认知一致。例如：

所有区域的前一日业务数据，在总部汇总时，归属到总部时区中包含该区域业务日结束时间的自然日。

3. UTC仅作为底层存储标准 #

UTC时区通常用于系统底层的时间戳存储，保证时间数据的统一性，但在业务汇总、报表展示层面，必须对齐业务主体的时区，避免用UTC日期直接替代业务日期，否则会导致业务数据与实际经营场景不符。

落地建议 #

• 保留现有区域数据清洗逻辑不变（按区域本地时间凌晨1点处理前一日数据）
• 在总部汇总环节新增映射规则：将区域提交的“本地前一日数据”，根据该区域业务日的结束时间，映射到总部时区对应的自然日，完成归属分类。

内容的提问来源于stack exchange，提问作者Jinwoo Chung