最新的可能FILETIME

我正在创build一个模拟对象来testing我的应用程序,使其在边界条件下工作。 我正在使用Windows SDK中的FILETIME 。

链接显示最早的时间是1601年1月1日(我假设午夜00:00:00,并且dwLowDateTime和dwHighDateTime都是0x00000000),所以我有这个。 什么是最新的FILETIME?

我的第一个直觉是将dwLowDateTime和dwHighDateTime设置为0xFFFFFFFF,但后来我质疑是否真的是一个有效的时间,我需要testing,因为我的链接页面说SetFileTime函数使用0xFFFFFFFF来指定应保留一个文件的以前的访问时间。

Solutions Collecting From Web of "最新的可能FILETIME"

对于那些仍然对FILETIME限制感兴趣的人:我的理解是, FILETIME是用来代表任何有效的64位的SYSTEMTIME 。 如果你采用SYSTEMTIME的限制(在30827中最后一个毫秒),那么你最终将通过使用SystemTimeToFileTime()来获得0x7fff35f4f06c58f0FILETIME 。 但是,如果将0x7fffffffffffffff放入FileTimeToSystemTime()则最终将在30828年,尽管此日期对SYSTEMTIME无效。 任何较大的值( 0x8000000000000000及以上)都会导致FileTimeToSystemTime()失败。 总而言之,我建议不要超越0x7fff35f4f06c58f0以保持兼容SYSTEMTIME

在这个MSDN文章–RTC实时功能测试的测试用例中有一个答案:“测试寻找以尽可能小的FILETIME(FILETIME 0是1601年1月1日开始)开始的范围,并以最大可能的FILETIME (最大FILETIME是最大的64位值)“。

根据链接,FILETIME表示:

…自16011月1日 (UTC)以来的100纳秒间隔的数量。

所以不是1970年1月1日。

它也说

… SetFileTime函数[例如]使用0xFFFFFFFF来指定应该保留一个文件以前的访问时间。

所以我不认为你会希望0xFFFFFFFF是一个有效的最大值。

根据专利6853957 ,该范围是在该时代之前/之后(1601年1月1日)的3万年。 这意味着你可以使用它与否定日期(即在时代之前的日期)。

编辑:只是计算:它可以存储(约)58454天100纳秒的间隔价值,所以+/- 30000年听起来像是一个很好的价值,如果你接受否定日期当然。