最近在做一个基于P2P的目录文件自动同步软件，开发环境用VC++ 2003，主要用QT FRAMEWORK而不是MFC（其实不会MFC）来实现跨平台用途，通信部分主要用UDT+TCP，UDT是基于UDP并实现了可靠传输的应用层的协议，用UDT也是因为它为NAT穿透的实现提供了理论上的可行性（基于UDP，当然不是说TCP无法打洞，而是实现相对复杂而且成功率低）。
虽然QT提供了尽可能多的功能，我也尽量用QT提供的功能而不是平台特定的一些功能，但QT毕竟不是万能，我在做修改文件最后修改日期时间（因为同步时候要判断文件最后修改日期时间，从而对重名文件进行合理同步）的时候，找遍了QT（我是用QT 3.3.4，也许最新的QT4提供吧）也没找到此类功能。没办法，这部分只有自己来实现跨平台了。独立出此功能的接口，编译时宏判断当前平台，接下来就可以用平台独立的函数了。因为我的确对WINAPI不熟悉，好不容易找到一个叫做SetFileTime的WINAPI函数，查看MSDN找到使用方法，因为SetFileTime接受的是FILETIME类型，FILETIME又无法直接修改具体日期时间，于是定义一个SYSTEMTIME变量，设定好日期时间，然后用SystemTimeToFileTime把SYSTEMTIME转换为一个FILETIME类型，最后用SetFileTime。本以为这样就大功告成，结果程序调试时候老是不停在同步更新，我觉得奇怪，按理说一段时间后，所有机器的同步目录下的文件应该保持稳定，就不在更新了。开始还怀疑是逻辑问题，但跟踪了半天都没发现问题，最后发现凡是调用SetFileTime的文件，其修改日期都比我设定的日期多了8个小时，想到中国本地又是GMT+8。于是查找MSDN，发现还需要调用LocalFileTimeToFileTime把当前的本地时间转换为UTC标准时间。再次测试一切正常！
具体代码类似如下：
#ifdef WIN32 SYSTEMTIME systime; FILETIME ft, ftUTC; HANDLE hFile; systime.wYear = l_year; systime.wMonth = l_month; systime.wDay = l_day; systime.wHour = l_hour; systime.wMinute = l_minute; systime.wSecond = l_second; systime.wMilliseconds = l_millsecond; SystemTimeToFileTime(&systime, &ft); LocalFileTimeToFileTime(&ft,&ftUTC); hFile = CreateFile( filePathName, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ| FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); SetFileTime(hFile, (LPFILETIME) NULL, (LPFILETIME) NULL, &ftUTC); CloseHandle(hFile);#endif