最新的FILETIME

Question

我正在创建一个模拟对象来测试我的应用程序，以便它在边界条件下工作。我在Windows SDK中使用FILETIME。

链接显示最早的时间是1601年1月1日（我假设是午夜00:00:00，dwLowDateTime和dwHighDateTime都是0x00000000），所以我有那。什么是最新的FILETIME？

我的第一直觉是将dwLowDateTime和dwHighDateTime设置为0xFFFFFFFF，但后来我质疑这是否真的是我需要测试的有效时间，因为我的链接页面在哪里表示SetFileTime函数使用0xFFFFFFFF指定应保留文件的先前访问时间。

Answer 1

我的理解是FILETIME代表64位中的任何有效SYSTEMTIME。如果您采用SYSTEMTIME的限制（30827中的最后一毫秒），则使用SystemTimeToFileTime()最终得到FILETIME 0x7fff35f4f06c58f0。

但是，如果您将0x7fffffffffffffff放入FileTimeToSystemTime()，那么您将在30828年结束，但此日期对SYSTEMTIME无效。任何较大的值（0x8000000000000000及更高版本）都会导致FileTimeToSystemTime()失败。

总而言之，我建议您不要超越0x7fff35f4f06c58f0以保持与SYSTEMTIME的兼容。

Answer 2

根据链接，FILETIME代表：

  

......自 1601年1月1日（UTC）以来的100纳秒间隔数。

所以不是1970年1月1日。

它也说

  

... SetFileTime函数[例如]使用0xFFFFFFFF指定应保留文件的先前访问时间。

所以我认为你不希望0xFFFFFFFF成为有效的最大值。

根据patent 6853957，范围是在纪元（1601年1月1日）之前/之后30，000年。这意味着你也可以将它与负日期（即纪元之前的日期）一起使用。

编辑：刚刚计算：它可以存储（大约）58,454天的100纳秒间隔，所以+/- 30，000年听起来像是一个很好的价值，如果你当然接受负面日期。

Answer 3

这篇MSDN文章中有一个答案 - Test Cases for the RTC Real-Time Functions Test：

  

测试查找以最小可能的FILETIME开头的范围（FILETIME 0是1601年1月1日的开始），并以最大可能的FILETIME结束（Max FILETIME是最大64位值）。