時間の境界条件で動作するように、アプリケーションをテストするためのモックオブジェクトを作成しています。WindowsSDKで使用FILETIMEしています。
リンクには、1601年1月1日（午前0時00分00秒と両方を想定していますdwLowDateTime）dwHighDateTimeの最も早い時刻が表示0x00000000されているので、それがあります。最新の可能なFILETIMEは何ですか？
私の最初の本能は、を設定dwLowDateTimeするdwHighDateTimeことですが、リンクされたページで、関数がファイルの以前のアクセス時間を保持するように指定するために使用0xFFFFFFFFする場所があるため、それが本当にテストする必要のある有効な時間であるかどうかを疑問視しました。SetFileTime0xFFFFFFFF
私の理解では、64ビットでFILETIME有効なものを表すために作られました。(30827 の最後のミリ秒)SYSTEMTIMEの制限を取ると、.SYSTEMTIMEFILETIME0x7fff35f4f06c58f0SystemTimeToFileTime()
ただし、 を入力すると、最終的には 30828 年になりますが、この日付は では無効0x7fffffffffffffffです。より大きな値 (以上) を指定すると、失敗します。FileTimeToSystemTime()SYSTEMTIME0x8000000000000000FileTimeToSystemTime()
0x7fff35f4f06c58f0全体として、 との互換性を維持するために、これを超えないことをお勧めしSYSTEMTIMEます。
リンクによると、FILETIMEは次のことを表します。
... 1601年1月1日（UTC）以降の100ナノ秒間隔の数。
1970年1月1日ではありません。
それはまた言います
... SetFileTime関数[たとえば]は、0xFFFFFFFFを使用して、ファイルの以前のアクセス時間を保持するように指定します。
したがって、0xFFFFFFFFが有効な最大値になるとは思わないでしょう。
特許6853957によると、範囲はエポック（1601年1月1日）の前後3万年です。これは、負の日付（つまり、エポックより前の日付）でも使用できることを意味します。
編集：計算したばかり：100ナノ秒間隔の58、454日分を保存できるので、もちろん負の日付を受け入れる場合は、+ /-30、000年が適切な値のように思えます。
この MSDN の記事 - Test Cases for the RTC Real-Time Functions Test に回答があります。
このテストでは、可能な限り最小の FILETIME (FILETIME 0 は 1601 年 1 月 1 日の始まり) で始まり、可能な限り最大の FILETIME (最大 FILETIME は最大 64 ビット値) で終わる範囲を探します。