跨时区场景下按天统计类应用的数据处理方案探讨

1. 绑定固定统计时区+锁定已结算周期 #

• 给每个用户指定一个固定统计时区：首次使用时默认用注册时的本地时区，也允许用户手动设置并锁定（比如选「北京时间」或「纽约时间」）。所有事件的日期归属，一律按这个固定时区的日期计算，和当前设备实时时区无关。
• 解决核心问题：用户跨时区移动时，历史事件的日期归属不会改变，已结算的得分、奖励不会被回溯修改。比如你在北京3月23日凌晨2点记录的事件，就归北京时区的3月23日，哪怕飞到美国切换了时区，这条记录还是属于3月23日，不会被划到美国的3月22日。
• 具体操作：
  • 存储事件时，同时记录UTC时间和用户的统计时区ID；
  • 到达统计时区的午夜时，自动结算当日得分和奖励，然后把该日数据标记成只读状态，之后任何操作都无法修改；
  • 若用户修改统计时区，仅对修改后的新周期生效，历史数据保持原统计结果不变。

2. 本地日绑定+周期锁定机制 #

• 记录事件时，除了UTC时间，同时存储事件发生时设备本地时区对应的日期（比如2023-03-23），但一旦这个日期对应的24小时周期结束，就把该日数据锁死，不允许后续跨时区操作修改。
• 解决核心问题：事件归属完全按发生时的本地时间计算，避免UTC转换带来的日期偏移；同时锁死已结束的周期，防止跨时区回退日期后修改已结算的得分。比如你在北京3月23日凌晨2点记录的事件归2023-03-23，飞到美国后设备显示3月22日，但此时北京的3月23日还没结束的话，新记录的事件归美国的2023-03-22，但不会影响北京3月23日的数据；要是北京的3月23日已经结算锁死，哪怕跨时区也无法修改。
• 具体操作：
  • 事件字段包含utc_time、local_date、local_timezone；
  • 后台按用户的本地时区计算周期结束时间，到午夜时自动锁死该local_date的数据；
  • 锁死的周期，拒绝任何新增、修改事件的请求，确保得分和奖励不会变更。

3. 参考Duolingo类应用的通用玩法：不回溯修改已结算数据 #

• 这类应用的核心规则就是历史数据一旦结算，绝不改动：
  • 初始默认用注册时区作为统计时区，允许用户手动调整；
  • 每日按统计时区的午夜结算，结算完成后当日的进度、奖励就固定下来；
  • 用户跨时区时，仅影响当前未结算的周期：如果统计时区的当日还没结束，跨时区后的新事件仍归属当日；要是当日已经结算完成，跨时区后的新事件直接归属统计时区的次日，不会回退到前一日。

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