18

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.

honk
  • 9,137
  • 11
  • 75
  • 83
xubia
  • 643
  • 9
  • 26
  • if you are looking to store information about file edits shouldn't you limit the changes to before the current time? It's makes no sense to have a last-modified time in the future. – twain249 Apr 03 '12 at 18:46
  • @tmain249 I certainly could use current time, and that would work if my question isn't answered. Thanks for the comment. I'm actually testing recorded video for like a security camera which of course requires a time stamp for each frame. – xubia Apr 03 '12 at 18:50

3 Answers3

22

My understanding is that FILETIME was made to represent any valid SYSTEMTIME in 64 bits. If you take the limit of SYSTEMTIME (last millisecond in 30827) then you end up with a FILETIME of 0x7fff35f4f06c58f0 by using SystemTimeToFileTime().

However, if you put 0x7fffffffffffffff into FileTimeToSystemTime() then you will end up in the year 30828, although this date is invalid for SYSTEMTIME. Any larger value (0x8000000000000000 and above) causes FileTimeToSystemTime() to fail.

All in all, I would recommend not to go beyond 0x7fff35f4f06c58f0 in order to stay compatible with SYSTEMTIME.

honk
  • 9,137
  • 11
  • 75
  • 83
  • 3
    According to the patent linked by @NickShaw the FILETIME has a range of +/- 30,000 years from its epoch of 1601. The actual range, however, is only +/- 29,227 (and some slop) from the epoch. And SYSTEMTIME is supposed to be from year 0 to year 65,535. So Microsoft didn't bother to accurately implement what they patented. :) – Jesse Chisholm May 26 '14 at 18:03
5

According to the link, FILETIME represents:

...the number of 100-nanosecond intervals since January 1, 1601 (UTC).

so not Jan 1st 1970.

It also says

...the SetFileTime function [for example] uses 0xFFFFFFFF to specify that a file's previous access time should be preserved.

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.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
Nick Shaw
  • 2,083
  • 19
  • 27
  • 1
    No problem. :) I'd also suggest that maybe you should do a reality test on the date instead of just boundary checking - anything beyond, say, the year 2100 is bound to be wrong... (unless your writing a game set in the distant future of course!) – Nick Shaw Apr 03 '12 at 19:03
  • True - we don't know yet on what weekday april 3, 31601 will fall. – MSalters Apr 03 '12 at 21:02
  • 2
    Even though the patent says FILETIME is +/- 30,000 years, it is actually a little less. 0x7FFFFFFFFFFFFFFF / 10,000,000 / 86,400 / 365.242198 is 29,227 years. So pick your programming limits accordingly. – Jesse Chisholm May 26 '14 at 17:55
  • @MSalters Yes, just because we aren't sure yet on 4000-year leap year rule. – ReinstateMonica3167040 Mar 30 '18 at 23:34
2

There is an answer in this MSDN article - Test Cases for the RTC Real-Time Functions Test:

The test looks for the range beginning with the minimum possible FILETIME (FILETIME 0 is the start of Jan 1st 1601) and end with maximum possible FILETIME (Max FILETIME is the maximum 64-bit value).

fedorqui
  • 275,237
  • 103
  • 548
  • 598
SChepurin
  • 1,814
  • 25
  • 17