我正在创build一个模拟对象来testing我的应用程序，使其在边界条件下工作。 我正在使用Windows SDK中的FILETIME 。
链接显示最早的时间是1601年1月1日（我假设午夜00:00:00，并且dwLowDateTime和dwHighDateTime都是0x00000000），所以我有这个。 什么是最新的FILETIME？
我的第一个直觉是将dwLowDateTime和dwHighDateTime设置为0xFFFFFFFF，但后来我质疑是否真的是一个有效的时间，我需要testing，因为我的链接页面说SetFileTime函数使用0xFFFFFFFF来指定应保留一个文件的以前的访问时间。
对于那些仍然对FILETIME限制感兴趣的人：我的理解是， FILETIME是用来代表任何有效的64位的SYSTEMTIME 。 如果你采用SYSTEMTIME的限制（在30827中最后一个毫秒），那么你最终将通过使用SystemTimeToFileTime()来获得0x7fff35f4f06c58f0的FILETIME 。 但是，如果将0x7fffffffffffffff放入FileTimeToSystemTime()则最终将在30828年，尽管此日期对SYSTEMTIME无效。 任何较大的值（ 0x8000000000000000及以上）都会导致FileTimeToSystemTime()失败。 总而言之，我建议不要超越0x7fff35f4f06c58f0以保持兼容SYSTEMTIME 。
在这个MSDN文章–RTC实时功能测试的测试用例中有一个答案：“测试寻找以尽可能小的FILETIME（FILETIME 0是1601年1月1日开始）开始的范围，并以最大可能的FILETIME （最大FILETIME是最大的64位值）“。
根据链接，FILETIME表示：
…自1601年1月1日 （UTC）以来的100纳秒间隔的数量。
所以不是1970年1月1日。
它也说
… SetFileTime函数[例如]使用0xFFFFFFFF来指定应该保留一个文件以前的访问时间。
所以我不认为你会希望0xFFFFFFFF是一个有效的最大值。
根据专利6853957 ，该范围是在该时代之前/之后（1601年1月1日）的3万年。 这意味着你可以使用它与否定日期（即在时代之前的日期）。
编辑：只是计算：它可以存储（约）58454天100纳秒的间隔价值，所以+/- 30000年听起来像是一个很好的价值，如果你接受否定日期当然。