Excel 日期转换：45366 不是 Bug，是格式而非值

用户通过我的转换器处理一份季度财务工作簿，得到的 Markdown 表格里，每一列日期都变成了整数：45366、45367、45368。而在 Excel 里，同样的单元格显示的是 2024-03-15。我最初以为是文件损坏了。但其实不是——转换器展示的是原始真相。

XLSX 以序列号的形式存储日期：从某个纪元算起的天数，加上时间的小数部分（0.5 表示中午）。文件里根本不存在 "2024-03-15" 这个字符串。让单元格看起来像日期的是 styles.xml 中的数字格式代码——yyyy-mm-dd 附加在单元格的样式上。Excel 在显示时应用这个格式。我的转换器读取的是值，而不是样式，所以整数是诚实的输出。

纪元本身就是一个陷阱。Excel 的日历名义上从 1900 年开始，但包含了一个虚构的 1900 年 2 月 29 日——这是一个存活了四十年的 Lotus 1-2-3 兼容性问题——所以直接算天数对于大多数现代日期会差一天。必须锚定在 1899-12-30 才能得到正确结果。而使用旧的 Mac 1904 日期系统创建的工作簿，在 workbook.xml 中带有一个标志，将每个序列号偏移 1462 天。忽略它，你的一半转换日期会在无声中出错，而且这种错误会持续多年才被发现。

修复方案：检测日期格式的样式，将序列号转换为 ISO 8601 字符串，遵循 1904 标志，并对有人在文本单元格中输入日期的情况保留启发式规则。时间小数部分也要能往返转换。

这个问题对 Agent 的影响比对人类更大，因为没有 Agent 会盯着表格看——45366 是一个完全合理的整数，它会直接进入摘要或 RAG chunk，看起来很权威。如果你正在将电子表格传送到 Agent 的上下文中，请检查你的转换步骤如何处理样式，而不仅仅是值。我把整个修复方案合并到了我的 XLSX-to-Markdown API（https://x402.freeq.one/tools/xlsx_to_markdown.html）中：相同的调用，日期现在以 ISO 字符串返回，而不是毫无意义的数字。