我正在创建一个模拟对象来测试我的应用程序，以便它在时间的边界条件下工作。我FILETIME在 Windows SDK 中使用。
该链接显示最早的时间是 1601 年 1 月 1 日（我假设午夜 00:00:00 并且两者都是dwLowDateTimeand dwHighDateTimeare 0x00000000），所以我知道了。最新可能的 FILETIME 是多少？
我的第一直觉是设置dwLowDateTime和dwHighDateTime设置0xFFFFFFFF，但后来我质疑这是否真的是我需要测试的有效时间，因为我的链接页面在哪里说该SetFileTime函数用于0xFFFFFFFF指定应保留文件的先前访问时间。
我的理解是，它FILETIME代表任何SYSTEMTIME64 位有效。如果您采用SYSTEMTIME（30827 中的最后毫秒）的限制，那么您最终FILETIME会0x7fff35f4f06c58f0使用SystemTimeToFileTime().
但是，如果您0x7fffffffffffffff输入FileTimeToSystemTime()then 您将在 30828 年结束，尽管此日期对SYSTEMTIME. 任何较大的值（0x8000000000000000及以上）都会导致FileTimeToSystemTime()失败。
总而言之，我建议不要超越0x7fff35f4f06c58f0以保持与SYSTEMTIME.
根据链接，FILETIME代表：
...自1601 年 1 月 1 日(UTC)以来的 100 纳秒间隔数。
所以不是 1970 年 1 月 1 日。
它还说
... SetFileTime 函数 [例如] 使用 0xFFFFFFFF 来指定应保留文件的先前访问时间。
所以我不认为你会期望 0xFFFFFFFF 是一个有效的最大值。
根据专利 6853957，范围是时代（1601 年 1 月 1 日）之前/之后的 30,000 年。这意味着您也可以将它与负日期（即纪元之前的日期）一起使用。
编辑：刚刚计算过：它可以存储（大约）58,454 天的 100 纳秒间隔，因此如果您当然接受负日期，+/- 30,000 年听起来是一个不错的选择。
这篇 MSDN 文章中有一个答案 - RTC Real-Time Functions Test 的测试用例：
测试查找以最小可能 FILETIME 开始的范围（FILETIME 0 是 1601 年 1 月 1 日的开始）并以最大可能 FILETIME 结束（Max FILETIME 是最大 64 位值）。