先把问题解决
本例同一天2024-01-01在1900系统中为45292，在1904系统中为43830。把确认的1904序列送入1900目标时加1462；反向减1462。始终保留原序列、来源系统和一个已知日期作为验收锚点。
先区分三种“日期”
屏幕上的2024-01-01可能来自数值序列加日期格式，也可能只是文本。外观相同不能证明底层含义相同。把副本中的单元格暂改为常规格式，只用于观察，不要覆盖原件；还应在工作簿设置中记录日期系统。
Microsoft日期系统说明确认两套基准相差1462天，并列出Windows和Mac的设置入口。不能仅凭电脑品牌判断；导出程序、旧模板与人工设置都会影响实际文件。
日期格式只改变显示方式，不替代来源核查。若只有CSV中的43830，却没有基准与已知日期，不足以确认它就是2024-01-01，也可能是一个编号。此时先向来源方确认，保留未知，不做“猜测修复”。
一份可以手算核对的交付清单
下面是编辑设计的材料，不是真实订单，也不声称已运行Microsoft Excel。两家门店上报同一天，第三份材料已转换，第四份是明确的文本日期；所有日期均不涉及时区时刻。
| 材料 | 源值与类型 | 已确认状态 | 目标值 |
|---|---|---|---|
| A | 45292，数值日期 | 1900系统 | 45292 |
| B | 43830，数值日期 | 1904，尚未转换 | 45292 |
| C | 45292，数值日期 | 从1904已转换 | 45292，不再加 |
| D | 2024-01-01，文本 | 明确日历日期 | 保留文本或按目标规则另行解析 |
只给已确认的数值日期转换一次
先在交付副本旁建三列：raw_serial、source_system、target_serial。A行原样复制，B行计算43830+1462=45292，C行保持45292。把“已转”状态与结果一起交付，避免下一次接收又转换。
反向案例也要检查：1900目标值45292送入明确采用1904系统的接收方时，45292−1462=43830。加减方向由来源与目标决定，不由屏幕显示“早了”还是“晚了”的直觉决定。
不要为修复某几行而盲目切换整本工作簿的日期系统。那会影响其他日期的解释；保留只处理受影响字段的副本更容易逐行验收。包含小数的日期时间还要保留时间部分；不要取整后丢掉时刻。
重复转换的识别
C: 45292 + 1462 = 46754
C: 保持45292；转换记录为already-normalized
用两个已知日期和边界行验收
除了2024-01-01，再放一个相邻已知日期2024-01-02：1900序列45293、1904序列43831。两行各自相差1462，相邻日期仍只差1，才能排除手工错位。
回查源文件、目标文件和记录ID：行数未变化，非日期金额和编号未改，空日期没有补成基准日，明确文本没有被重复加数。保存并重新打开最终交付文件，按接收方的软件确认显示。
交付纯文本时明确写YYYY-MM-DD与字段类型；这表示日历日期，不是某个时区的午夜。接收方仍需决定导入为文本还是日期。不要用文本交付掩盖未确认的源序列。
验收清单
- 每份源文件都有日期系统记录与至少一个已知日历日期。
- 转换范围只含已确认的数值日期，不含文本、空值、编号。
- A/B/C统一到45292，下一日统一到45293。
- 原件、修复副本、字段类型与转换记录同时可追溯。
日期含义统一后，再处理合表
先完成上述归一化，再按不同表头合表方法对齐字段。合并行并不自动证明日期含义已统一；同一列名也可能装着不同基准的数值。
若输出CSV，还要读公式缓存与多工作表导出限制。CSV不携带完整工作簿设置，最好附来源与字段说明。本文未声称本站转换器或Excel所有粘贴路径都会自动纠正这两套日期系统。
常见问题
相差四年就一定是日期系统吗？
不一定。1462天且来源设置、已知日期、转换状态都吻合才是较强证据。年份输入错误、两位年份解释和文本解析是其他独立原因。
