I'm creating a mock object to test my application so that it works at the boundary conditions of time. I'm using FILETIME
in the Windows SDK.
The link shows the earliest time which is January 1, 1601 (I'm assuming midnight 00:00:00 and both dwLowDateTime
and dwHighDateTime
are 0x00000000
), so I have that. What is the latest possible FILETIME?
My first instinct is to set dwLowDateTime
and dwHighDateTime
to 0xFFFFFFFF
, but then I questioned if that really is a valid time that I need to test, due to where my linked page says the SetFileTime
function uses 0xFFFFFFFF
to specify that a file's previous access time should be preserved.
My understanding is that
FILETIME
was made to represent any validSYSTEMTIME
in 64 bits. If you take the limit ofSYSTEMTIME
(last millisecond in 30827) then you end up with aFILETIME
of0x7fff35f4f06c58f0
by usingSystemTimeToFileTime()
.However, if you put
0x7fffffffffffffff
intoFileTimeToSystemTime()
then you will end up in the year 30828, although this date is invalid forSYSTEMTIME
. Any larger value (0x8000000000000000
and above) causesFileTimeToSystemTime()
to fail.All in all, I would recommend not to go beyond
0x7fff35f4f06c58f0
in order to stay compatible withSYSTEMTIME
.According to the link, FILETIME represents:
so not Jan 1st 1970.
It also says
So I don't think you would expect 0xFFFFFFFF to be a valid max value.
According to patent 6853957, the range is 30,000 years before/after the epoch (Jan 1, 1601). That implies you can use it with negative dates (i.e. dates before the epoch) too.
EDIT: Just calculated: it can store (approx) 58,454 days worth of 100-nanosecond intervals, so +/- 30,000 years sounds like a good value to go with, if you accept negative dates of course.
There is an answer in this MSDN article - Test Cases for the RTC Real-Time Functions Test: