日期导入错误往往不会让程序报错：一个合法日期被转换成另一个合法日期，行数、金额总计仍然一致，按月报表却已经失真。本文限定于 Excel 工作簿及其数据接入，主要以 XLSX 和所引用的 openpyxl 文档解释机制；旧 XLS、CSV 和其他读取引擎必须分别验证。示例为构造数据与规则推导，不代表生产测试。
先判断字段含义，再决定是否转换日期
CSV 导入的数据保真检查提醒我们保留来源表示。Excel 接入还多了一层：单元格显示、底层值、工作簿日期系统和业务字段含义可能不同。截图中的“2026-11-03”不足以说明程序读到的是文本、日期对象还是序列数字，更不能证明它代表某个带时区的瞬间。
第一步先给字段分型：业务日期，例如合同生效日；本地日期时间，例如某工厂交班时间；绝对时刻，例如具有明确时区来源的事件；持续时间，例如设备停机三十六小时；以及本来就不是日期的编号。目标类型不同，合法转换路径也不同。
显示格式只能提供线索，不能代替业务契约。数值 1.5 若代表天数持续时间，应是三十六小时；若代表普通测量值，就不应进行日期转换。将整列自动套上日期解析，再根据是否报错决定类型，会把这种语义差异变成隐蔽的数据污染。
对每个来源模板，记录工作表、字段位置、允许的存储类型、日期系统读取方式、文本格式、时区来源、空值政策和允许范围。模板修订后重新验证，不能因为列名仍叫“时间”，就继承旧模板的全部假设。
1900 与 1904 系统的差异必须来自工作簿证据
Microsoft 文档说明 Excel 支持 1900 与 1904 两种日期系统，同一个常用现代日期的序列值相差 1462 天。[1] 这是数值解释规则的差异，不是显示格式不同；因此仅把单元格格式改成日期，并不能纠正错误的基准。
用官方文档给出的日期检查转换方向：2011-07-05 在 1900 系统中为 40729，在 1904 系统中为 39267。[1] 若要把同一天的 1904 序列改成 1900 序列，需要加 1462；反向需要减 1462。业务日期本身不应改变。
但生产接入不宜先对所有数值加减这个常数。读取引擎可能已依据工作簿元数据生成正确的日期对象；再次补偿就造成二次转换。混合汇总多个文件时，更不能根据第一份文件的系统处理所有批次。应逐工作簿读取，再逐字段判断是否需要转换。
openpyxl 文档提供 wb.epoch 用于识别工作簿基准。[2] 接入记录应同时保留来源文件身份与读取到的基准，不能用操作系统、文件创建人或当前默认设置猜测。对于只剩裸序列值、已经丢失原工作簿的导出文件，应要求来源声明或权威对照值；无法确认时进入待核实状态。
历史兼容值、时分秒与持续时间分别处理
1900 日期系统存在历史兼容问题：它把实际上不存在的 1900-02-29 当作日期，Microsoft 解释该行为源于兼容性。[3] 所以不能把整个系统简单等同于“某个起点加天数”，再假定所有历史边界都符合真实公历。
针对序列值 60 对应的虚构日期，应在原始值仍可辨认时拦截并说明原因，不能悄悄改成相邻的真实日期。若通用读取器先把异常序列转换成与别的序列相同的日期对象，后续检查对象合法性已无法恢复区别。因此原始单元格证据应在有损转换前保留。
本文建议现代经营接口直接约定合理的日期下限，并把早期序列、负值和不符合业务范围的值隔离。真正需要历史日期的档案场景，应另建明确的文本日期或专用表示方案，不沿用为现代报表设计的自动导入规则。范围检查是业务保护，不能代替正确读取日期系统。
数值的小数部分通常用于一天中的时间，但同样的数值也可能表达持续时间。openpyxl 对相应持续时间格式支持 timedelta；日期时间对象本身不携带 Excel 中不存在的时区信息。[2] 接入应分别保存持续秒数、本地时钟值和业务日期，不能把三者统一塞进 timestamp 字段。
一条受控转换流程应保留哪些证据
接收完整文件后，保留受控原件和内容摘要，读取工作簿级日期系统，定位契约指定的列。暂存记录应包含文件身份、工作表、单元格坐标、原始类型、原始值、数字格式、读取器版本及读取结果。对可能提前转换日期的读取器，需验证其原始值获取路径；只有显示字符串不足以完成边界检查。
然后按类型分支。已经被可信读取路径解释成日期对象的值，核对其基准和字段契约后使用，不重复应用序列偏移；仍是数字的日期字段，必须与本工作簿基准一起转换；文本字段只接受已约定格式。遇到 03/04/2026，不应靠所在机器默认语言猜测月日顺序。
对于业务日期，保留年月日即可，不要擅自补成某地午夜并转 UTC。构造反例：本来表示 2026-11-03 的业务日期，被解释为北京时间当天零点，再转为 UTC，会落在 2026-11-02 的十六点；若下游按 UTC 日期分组，就把业务归属移到前一天。
对于本地日期时间，只有来源时区已知且歧义已解决，才转成绝对时刻；未知时区明确标为未知。持续时间则按约定单位输出数值，并检查是否允许负值或跨日。不要把三十六小时显示成十二点后丢失整天部分，也不要用补一个日期的方法掩盖类型不匹配。
若字段含公式，应另确认读取到的是公式、已有计算结果还是其他表示，以及结果是否对应当前输入。公式存在不证明结果新鲜，日期序列校验也不能证明公式已重新计算。无法证明计算状态时，应要求来源提供已确认的结果或使用经验证的计算流程。
用双工作簿和反例验证，而不是只比行数
第一组验收使用两个独立工作簿，分别设置两种日期系统，写入同一个已知现代日期。读取后的规范化业务日期应相同，原始序列应符合各自基准；再把两份数据混合导入，确认没有按首个文件统一偏移。测试应经过实际交付使用的读取和写入路径。
第二组对同一字段加入整数序列、带时间的小数序列、明确格式的日期文本、歧义文本、空值及超范围值。预先写出每项是接受、拒绝还是待核实；空值不得变成基准日期。对 1900 系统的 59、60、61 单独检查，要求 60 不被静默归并为真实日期。
第三组区分业务日期、时刻与持续时间。三十六小时应保留完整时长；午夜业务日期不得因时区转换改变日期；已声明时区的事件则应与独立参考时刻一致。目标数据库的字段类型、驱动和报表展示都纳入链路，不能只在 Python 对象层验收。
第四组做往返检查：从标准结果导出，再用目标工具重新读取，比对语义类型与值。比较的是约定精度下的日期或时长，不要求文件字节完全相同。往返一致仍不是充分证明，因为两个方向可能共享同一个错误；必须同时与独立已知日期核对。
对账按业务键逐记录比较日期，并核对各日、各月的数量分布。总行数和总金额相同无法发现整批跨年或跨月偏移。若允许部分成功，应同时交付接受数、隔离数与完整性状态，让下游知道报表是否缺失记录。
发现偏移后，修正转换规则而不是整表平移
当某些日期看起来相差四年，先按来源文件、日期系统、原始类型与读取器版本分组排查。可能只有部分文件基准错误，也可能已经发生过一次补偿；直接把正式表全部加减 1462 天，会破坏原本正确的记录。先定位受影响集合，再生成差异预览。
修复应使用原始文件和明确的新转换规则，产生独立处理版本，比较旧新日期、业务分组与异常数量，并保留替换关系。对账通过后再切换受影响结果；失败时回到原正式版本，不把半批新日期暴露给问数或报表系统。
最终回执列明来源文件身份、日期系统、规则与读取器版本、接受和隔离数量、已验证类型以及未决项。日期接入的目标，是让每个日期仍然表示约定的业务事实。显示正常、能够入库和往返不报错，都只是其中一部分证据。