transcript
show notes
一个“永不过期”的最大时间戳，为什么会在 Windows API 之间变成溢出、相对时间，甚至是一条“不要修改时间”的控制命令？Raymond Chen 以 FILETIME 为例，拆解极端日期在不同 API、语言运行时与日历系统中不断改变语义的隐蔽风险。
本期对原文进行深度解析：真正危险的并非某个 API 明确拒绝边界值，而是多个组件都能接受它，却各自赋予不同含义。与其让魔法值伪装成日期，不如用类型明确表达“永不过期”“未知”等业务状态。欢迎阅读原文，了解完整的 Windows 时间处理边界与设计细节。
原文链接：
https://devblogs.microsoft.com/oldnewthing/20260921-00/?p=112711/
原文标题：What’s the highest legal FILETIME? Is it safe to use?
主要内容：
• FILETIME 的全一值 `0xFFFFFFFFFFFFFFFF` 虽然在比较中最大，但传给 `SetFileTime` 时代表“不要更新此时间”，从数据变成了控制信号。
• 许多时间 API 会按有符号整数解释同一位模式：高位为一的“极晚日期”可能被当作相对等待时长或异常的历史时间。
• `FileTimeToSystemTime` 可将最大非负 FILETIME 转为 30828 年，但 `SystemTimeToFileTime` 的支持范围更窄，无法完成原样往返。
• 边界值还会受闰秒数据、时区换算、日期运算影响；一次“加一天”或本地化转换就可能触发失败或溢出。
• 跨语言和跨系统会进一步收窄可用范围，例如 .NET `DateTime` 最多到 9999 年，特定历法的上限更早。
推荐理由：
这篇文章把一个底层 API 边界问题，提炼为通用的软件设计原则：合法可比较，不等于可在整条处理链中安全流转。它特别值得工程师深入阅读，因为它揭示了类型系统之外的“隐形协议”如何制造跨组件 bug，并给出更可靠的替代方案——用 `std::optional`、`Nullable` 或明确状态标签表达特殊业务语义，而不是滥用一个遥远的时间值。
---
「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。
由 voieech.com 提供技术支持。
