What is the proper way to convert a FILETIME
structure into __int64
? Can you please tell me?
7 Answers
I don't think you're suppose to: "Do not cast a pointer to a FILETIME
structure to either a ULARGE_INTEGER*
or __int64*
value because it can cause alignment faults on 64-bit Windows."
If you really wanted it would be something like:
__int64 to_int64(FILETIME ft)
{
return static_cast<__int64>(ft.dwHighDateTime) << 32 | ft.dwLowDateTime;
}
FILETIME ft = // ...
__int64 t = to_int64(ft);
But something like:
FILETIME ft = // ...
__int64 t = *reinterpet_cast<__int64*>(&ft);
Is bad.
-
1How about memcpy(<__int64>, &FILETIME, 8); ? Is it safe? – akif Oct 14 '09 at 15:42
-
1I would find `memcpy` harder to understand, but I'm sure it would work. The compiler can probably optimize shift and or better. – GManNickG Oct 14 '09 at 15:51
-
Indeed, it was harder to understand, but it has worked so far :) Thanks – akif Oct 15 '09 at 04:35
-
If one wants to convert it to UNIX time, one has to use something like https://stackoverflow.com/questions/20370920/convert-current-time-from-windows-to-unix-timestamp-in-c-or-c. – keineahnung2345 Sep 07 '21 at 03:35
There is no need to revert to arcane constructs using bitwise OR's. The Windows API has got everything you need to do this.
unsigned __int64 convert( const FILETIME & ac_FileTime )
{
ULARGE_INTEGER lv_Large ;
lv_Large.LowPart = ac_FileTime.dwLowDateTime ;
lv_Large.HighPart = ac_FileTime.dwHighDateTime ;
return lv_Large.QuadPart ;
}
Or if you want to go to __int64 directly.
__int64 convert_to_int64( const FILETIME & ac_FileTime )
{
return static_cast< __int64 > ( convert( ac_FileTime ) ) ;
}

- 3,170
- 23
- 24
-
4These days (since C++11) it can simply be written as `ULARGEINTEGER{ ft.dwLowDateTime, ft.dwHighDateTime }.QuadPart`. Arguably not more readable however you don't need any additional function/macro. – klaus triendl Nov 08 '18 at 19:23
Try
(__int64(filetime.dwHighDateTime)<<32) | __int64(filetime.dwLowDateTime)

- 23,670
- 6
- 53
- 72
Of course you could just pass in an __int64 casted to a filetime as follows *(FILETIME*)&int64Val. This will work fine under Visual C++.
ie
__int64 createTime = 0;
__int64 accessTime = 0;
__int64 writeTime = 0;
GetFileTime( hFile, *(FILETIME*)&createTime, *(FILETIME*)&accessTime, *(FILETIME*)&writeTime );

- 61,365
- 24
- 124
- 204
-
"Do not cast a pointer to a FILETIME structure to either a ULARGE_INTEGER* or __int64* value because it can cause alignment faults on 64-bit Windows." https://learn.microsoft.com/en-us/windows/desktop/api/minwinbase/ns-minwinbase-filetime – MrTux Mar 09 '19 at 16:10
-
2@MrTux: In the link it says that you mustn't cast FROM a FILETIME structure. The 2 meanings are very different. Basically a FILETIME might be on a 4 byte alignment (or maybe even a 2) and so casting to an __int64 will cause alignment issues as an __int64 is necessarily 8 byte aligned. However in the function above I pass in an 8 byte aligned __int64 and windows writes into it. It doesn't change the address of the pointer just because its an __int64. That would break all kinds of things. – Goz Mar 11 '19 at 11:00
-
Really like this answer, because it makes perfect sense in the light of the *real* meaning of the documentation advise; and the [description by Raimond Chen](https://devblogs.microsoft.com/oldnewthing/?p=38053). Thanks tor intelligent advise! – Mike Kaganski Jul 09 '19 at 03:37
you can try the code follow. the code is from chromium project
template <class Dest, class Source>
inline Dest bit_cast(const Source& source) {
Dest dest;
memcpy(&dest, &source, sizeof(dest));
return dest;
}
//FILETIME to __int64
__int64 FileTimeToMicroseconds(const FILETIME& ft) {
return bit_cast<__int64, FILETIME>(ft) / 10;
}
void MicrosecondsToFileTime(__int64 us, FILETIME* ft) {
*ft = bit_cast<FILETIME, __int64>(us * 10);
}
int _tmain(int argc, _TCHAR* argv[])
{
__int64 nTmpUint64 = 13060762249644841;
time_t unixtime;
FILETIME nTmpFileTm;
MicrosecondsToFileTime(nTmpUint64,&nTmpFileTm);
return 0;
}
I had exactly the same issue, googled for it, and came here. But I also found a useful Microsoft support page at
https://support.microsoft.com/en-gb/help/188768/info-working-with-the-filetime-structure
It says:
Performing Arithmetic with File Times
It is often necessary to perform a simple arithmetic on file times. For example, you might need to know when a file is 30 days old. To perform an arithmetic on a file time, you need to convert the FILETIME to a quadword (a 64-bit integer), perform the arithmetic, and then convert the result back to a FILETIME.
Assuming ft is a FILETIME structure containing the creation time of a file, the following sample code adds 30 days to the time:
ULONGLONG qwResult;
// Copy the time into a quadword.
qwResult = (((ULONGLONG) ft.dwHighDateTime) << 32) + ft.dwLowDateTime;
// Add 30 days.
qwResult += 30 * _DAY;
// Copy the result back into the FILETIME structure.
ft.dwLowDateTime = (DWORD) (qwResult & 0xFFFFFFFF );
ft.dwHighDateTime = (DWORD) (qwResult >> 32 );
Edit: I realise this merely confirms some of the other answers, but I thought it was worth adding for clarification.

- 121
- 2
- 5
Three ways that have best performance (one assembler instruction). Tested only in Visual C++ 2022 x64.
auto u = std::bit_cast<std::uint64_t>(ft)
The best way.
auto u = *reinterpret_cast<std::uint64_t _UNALIGNED*>(&ft)
Disadvantage: _UNALIGNED
macro (and __unaligned
modifier) is non-standard. But almost every compiler has this modifier in some form.
memcpy(&u, &ft, sizeof(u))
Disadvantage: this code will be well optimized only if you turn on “Enable Intrinsic Functions” C++ compiler option.
Other answers have some overheads.
(static_cast<std::uint64_t>(ft.dwHighDateTime) << 32) | ft.dwLowDateTime
Generates bitwise operations.
ULARGE_INTEGER{ft.dwLowDateTime, ft.dwHighDateTime}.QuadPart
Generates two 32-bit operations instead of one 64-bit one.

- 939
- 8
- 13
-
what the compiler does with the _unaligned cast will vary between platforms; don't recommend it. My preferred solution is to actually just use uint64_t for all FILETIME variables and reinterpret_cast as needed for the interfaces (which is perfectly safe as uint64_t has the required 8 byte alignment, but FILETIME only has 4 byte alignment). I also do this for LARGE_INTEGER to avoid having to monkey with QuadPart – nfries88 Feb 23 '23 at 22:57