系统时间与业务时间不一致的处理

现象

• 报工记录的时间比实际早/晚 8 小时
• 跨天统计把昨天的算到今天
• 班次归属错误（夜班的产量算到白班）
• 导出的 Excel 时间格式不对

三类原因

一、时区问题

这是最典型的：相差正好 8 小时（或时区差）。

常见场景：

如果数据在某一环节按 UTC 存储，另一环节按本地时间读取，就会差 8 小时。

排查：

1. 看数据库里存的实际值
2. 看接口返回的值
3. 看页面显示的值

三个值对比，就能定位是哪个环节转换错了。

二、服务器时间不准

服务器时钟没有 NTP 校时，长期运行后漂移。

表现：时间差是不规则的（几分钟到几十分钟），而不是整小时。

排查：在服务器上执行 date 命令，与标准时间对比。

解决：配置 NTP 校时。

三、业务日历问题

系统时间是对的，但业务上归属错了。

常见场景：

• 跨天班次：夜班从 20:00 到次日 8:00，跨了两个自然日。如果统计按自然日切分，夜班产量会被拆到两天。
• 班次边界：交接班时间点的报工算哪个班？需要明确定义。
• 盘点日/结账日：财务的"日期"可能与自然日不同。

这类问题不是 bug，是配置或定义问题。

排查步骤

第一步：确定差异特征

第二步：三处对比

取同一条记录，对比：

1. 数据库中的时间值
2. 接口返回的时间值
3. 页面上显示的时间值

再加上一个：其他系统（比如 ERP）里同一条业务记录的时间。

四个值一对比，问题定位就很清楚了。

第三步：检查各环节时区配置

统一时区的建议

存储用统一标准

推荐做法：数据库统一存 UTC，展示时按用户本地时区转换。

或者，更简单的做法：全部统一用本地时间（UTC+8），不做转换。

后者的优点是不容易出错，缺点是如果有跨时区需求就得改。

对绝大多数国内制造企业，第二种更实用。

关键是：全链路统一，不要有的地方用 UTC 有的用本地。混用必然出问题。

时间字段类型

建议用 DATETIME 存本地时间，避免自动转换带来的意外。

传输格式

接口传输时间统一用 ISO 8601 格式，并明确时区：

• 带时区：2026-09-10T14:30:00+08:00
• 不带时区：2026-09-10 14:30:00

建议明确带时区，避免接收方猜测。

跨天班次的处理

这是业务层面必须明确定义的。

方案一：班次归属日

规定"生产日"从早上 8:00 开始，到次日 8:00 结束。

那么 9 月 10 日 22:00 的产量，归属于 9 月 10 日生产日。

需要在系统里配置班次的起止时间，而不是简单按自然日 0:00 切分。

方案二：按班次统计而非按日

统计维度直接用班次（白班/夜班），不用自然日。

这样天然避开了跨天问题。

方案三：自然日 + 标注

按自然日统计，但标注清楚"夜班跨两个自然日"。

交接班边界的处理

交接班前后的报工怎么归属？

建议明确规定：

• 以报工提交时间为准 → 简单，但可能不准（交班后才补报）
• 以工单/工序的开工时间为准 → 更准确，但需要额外记录
• 以手动选择的班次为准 → 灵活，但可能选错

推荐第二种，虽然实现复杂点，但数据更真实。

预防措施

一个检查清单

上线前逐项确认：

• 所有服务器的时区一致
• 数据库时区配置明确
• 应用服务时区配置明确
• 接口时间格式明确定义
• 前端时间显示逻辑确认
• 班次起止时间配置正确
• 跨天统计规则明确定义
• NTP 校时已配置
• 用真实数据验证过时间正确性

时区与班次配置说明，[待补充：百华智造 MES 时区与班次配置指南]。