GNU date 只在某一天报 invalid date：检查历史时区中不存在的午夜

定时脚本处理前后日期都正常，到了某个历史日期却报 date: invalid date，重启也没有变化。若输入格式正确，还要检查它被解释成了哪个时区的哪个时刻。GNU date 的日期解析涉及当地时间；一个有效的日历日，不保证该时区当天的 00:00 真的存在。

以下针对 GNU coreutils 的 date，以及时区规则导致的当地时间空档。实际不存在的日期、非 ASCII 标点、格式错误或数值范围问题也会报 invalid date，不能看到这个字符串就认定是夏令时。

日期字符串可能隐含了本地午夜

只传年月日的输入可能以当天午夜作为时间部分，再按 TZ 或系统默认时区转换为时刻。在午夜发生向前拨钟的地区，当地时间会跳过一段区间，解析这个区间内的时间就可能失败。

例如 America/Sao_Paulo 在 2016-10-16 的历史规则中，从前一天 23:59:59 跳到当天 01:00:00，当天 00:00 至 00:59 的当地时间不存在。这个例子解释的是指定历史日期，不表示该地区现在仍按同样方式切换，也不能推断其他地区在同一日期有相同行为。

把语言环境改为 C，能够改变部分显示和解析环境，却不会让不存在的当地午夜变成有效时刻。重启也不会移除时区数据库中的历史规则。

保存原始输入、date 实现和版本、TZ 及任务实际运行环境。交互终端、cron、systemd 或容器可以使用不同的环境和时区数据，同一命令在另一台机器成功不能证明失败机器只是偶发错误。

支持 --debug 的 GNU date 可以显示有效时区、解析步骤和警告。以下是只显示日期的历史示例，不修改系统时间：

date --version
TZ=America/Sao_Paulo date --debug --date='2016-10-16'

检查诊断是否使用了午夜、是否指出当地时间不存在，以及解析后的年月日与原输入是否一致。debug 给出的可能原因需要结合时区规则核对，不能把其中列出的每项都当成已确认原因。旧版本不支持该选项时，应按实际版本的诊断能力处理；BSD、BusyBox 或其他实现也不能直接照抄 GNU 参数。

如果时区不是预期值，先检查任务环境和安装的时区数据。确认它们确实不符合项目要求后，再按平台流程纠正；不要为了让这一条命令成功，直接修改整台服务器的时区或系统时钟。

若任务只是在日期标签上加减天数，没有把输入当成真实发生的本地时刻，可以在这个计算步骤明确采用 UTC 的规则。例如：

TZ=UTC0 date --date='2016-10-16 - 2 days' +'%Y-%m-%d'

这里显式选择不使用夏令时的 UTC0，处理的是约定的日期计算。只有业务确实采用这种日期语义时才这样改；它不能替代“某地当天营业开始时间”或“某地某时发生的事件”的转换。

需要更复杂的日历规则时，可以由专门的日期处理逻辑直接处理年月日，不先把每个日期附会成一个当地午夜。月底、闰年及月度计算都有自己的规则，不能把任意加减月份当成固定秒数，也不能认为一个日历日永远对应 86400 秒的当地时间区间。

如果输入要求代表 America/Sao_Paulo 当地午夜，2016-10-16 这个要求没有对应的真实时刻。需要由业务决定遇到空档时拒绝输入、选择第一个有效时刻，还是按另一套明确规则处理，并保留这一取舍。

给输入补 12:00 可能绕过这个具体午夜空档，但也把请求的时间改成了中午；它不是通用修复。其他地区的时钟调整可能发生在别的时间，甚至跳过更大的区间。

同样，把一份当地时间直接标成 UTC 会改变所代表的时刻。若用于查询某地一天的数据，应按该地区实际有效的日界和下一天日界建立范围，再确认边界的包含关系；不要只为避开报错，把已有时间戳统一加一小时或重写成 UTC。

在隔离数据中覆盖失败日期、相邻日期、当前时区普通日期以及项目涉及的其他时钟切换边界。检查计算得到的日期、偏移或时刻符合业务规则，且批次没有漏处理或重复处理。

日期解析失败时，原流程应停止或记录失败批次，不能把空输出继续当成有效日期传给归档、删除或数据库查询。改动只限定在所需计算步骤时，也要确认它没有改变后续命令应使用的当地时区。

回退时恢复保存的脚本和任务环境，并暂停可能采用错误日期的重跑。已经按错误日期归档、发送或修改的数据，需要依据原批次记录恢复；撤回 TZ 或解析代码不会撤销这些业务操作。