Win32 FileTime bug?

[kris]

There's something odd going on; either it's me or it's the Win32 
FileTime APIs :)

FileTime is supposed to return the number of 100ns increments since 
1601AD. Yet, when you use GetSystemTimeAsFileTime() and convert to a 
ulong it provides a number that appears to be a power of 10 too big.

Example:

# FILETIME fTime;
# GetSystemTimeAsFileTime (&fTime);
# ulong tmp = (cast(ulong) fTime.dwHighDateTime) << 32 |
#                          fTime.dwLowDateTime;


as of right now, tmp is 127900383052656250

(using MS Calculator)

divide by 10,000,000 to convert into seconds: 12790038305.265625
divide by 360 to get hours: 35527884.181293402777777777777778
divde by 24 to get days: 1480328.5075538917824074074074074
divide by 365 to get ~years: 4055.6945412435391298833079654997

OK; apparently 2006AD minus 1601AD is 4055 years :)

At this point, one might think "oh, the documentation is wrong; it's 
really counting 10ns intervals instead of 100ns". Well, that doesn't pan 
out since if you print the resultant conversion in a loop, with a one 
second sleep() between each line, the time-passage is represented in the 
correct decimal position vis-a-vis the 100ns interval. So, no luck there.

A similar thing happens with SystemTimeToFileTime().

Any ideas? Am I being really dumb today?