3. 上下游企业追溯数据时间戳错位排查
问题场景与排查思路
某乳制品追溯链在跨企业查询时出现断裂：上游牧场记录的挤奶时间为 2024-06-12 05:40:00，下游加工厂接收原料记录为 2024-06-12 13:40:00，两者相差 8 小时，导致按时间窗口关联批次时匹配失败。追溯链本身数据并未丢失，问题出在时间基准不一致。排查需沿三个方向并行：各系统时区配置、NTP 同步状态、接口时间字段格式。
关键检查点与操作
排查时按以下顺序逐项确认，每项都需记录实际值以便比对：
- 时区配置：在 Linux 系统执行
timedatectl查看Time zone字段；数据库执行SHOW timezone;（PostgreSQL）或SELECT @@global.time_zone;（MySQL）；Java 应用检查-Duser.timezone启动参数。 - NTP 同步：执行
chronyc tracking或ntpq -p，关注System time偏移量是否在毫秒级；若Leap status为Not synchronised，说明时钟未同步。 - 接口时间格式：抓取接口报文，确认时间字段是否为 ISO 8601 带偏移格式（如
2024-06-12T05:40:00+08:00）。若下游用LocalDateTime解析而丢弃了偏移量，则时间会被当作本地时间处理。
常见陷阱：上游发送带
+08:00 的时间，下游用 LocalDateTime.parse() 解析后存入数据库，偏移信息丢失，数据库按 UTC+0 存储，查询时再按 UTC+8 展示，就会出现 8 小时偏差。应使用 OffsetDateTime 或 ZonedDateTime 保留时区信息。统一时间基准的修复方案
定位到根因后，按以下方案统一时间基准：
- 将所有追溯相关系统的时区统一为
Asia/Shanghai（UTC+8），并在部署脚本中固化TZ=Asia/Shanghai环境变量。 - 为所有服务器配置 NTP 客户端，指向同一内网 NTP 源，确保时钟偏移小于 100ms。
- 接口层强制使用 ISO 8601 带偏移格式传输时间，下游解析使用
OffsetDateTime，数据库存储统一为 UTC 并在展示层转换。 - 对历史错位数据，按接口日志中的原始时间戳重新计算并修正，修正前先备份。
验证方法：修复后重新触发一次上下游追溯查询，确认同一批次在上游挤奶时间与下游接收时间的时间差在合理运输窗口内（如 2 小时内），且追溯链完整关联。可编写定时校验任务，对时间差超过阈值的记录自动告警。