案例：ASN 日期早了一天——跨时区事故复盘

先说结论：这是我们自己运营中踩过的坑，不是客户踩的。写出来，是因为市面上一半以上的"日期不对"类拒收，根子都是它。

发现

零售商系统反馈某批 ASN "did not have correct date"。单看任何一张报文都没毛病：格式合规、字段齐全、997 也收到了 A（接受）。但把拒收批次和正常批次放在一起排，规律出来了——出问题的报文全部生成于北京时间凌晨，也就是美西的下午三四点以后。

服务器在中国，系统取"今天"用的是服务器本地日期。北京时间过了半夜，服务器认为已经是"明天"，可美西的业务日还在"今天"——于是发货日期整整早了一天。零售商的校验逻辑很朴素：你说的发货日期还没到，这是一张来自未来的 ASN，拒。

更麻烦的是它的隐蔽性：白天生成的报文全对，只有特定时段的错。抽查抽不到，直到批量对账才现形。翻完历史数据，波及近三百笔。

当天：受影响报文重新生成重发，逐笔核对零售商侧状态；
当周：全链路排查所有取"当前日期"的位置——报文生成、定时任务的"今天"判断、报表归集，一律改为按美西时区（America/Los_Angeles，含夏令时自动切换）取日期；
长期：上线一条监控规则——发货日期晚于当前美西日期的报文直接拦下人工复核，同类问题从机制上不可能再流出。

判断你的服务商专不专业，可以拿这个问题当试金石："服务器在中国，报文日期按哪个时区取？夏令时切换那两天怎么处理？"答不上来的，早晚给你踩一遍。