最近、（実際には、いないMFC）の代わりにMFCのQTクロスプラットフォームの利用を達成するために、主にFRAMEWORK VC ++ 2003を使用して、P2Pベースのディレクトリのファイルに自動的に同期ソフトウェア開発環境をやって、通信部は、主にUDT + TCP、UDTはUDPに基づいて使用されていますそして信頼性の高い伝送のためのアプリケーション層プロトコルを実装するだけでなく、NATがUDPに基づいた理論的な可能性を（提供のUDTとその浸透を図るため、TCPはない穴を言うことが、比較的複雑で、低い成功率を達成することではありません）。
QTは、できるだけ多くの機能を提供していますが、私もQT機能ではなく、いくつかのプラットフォーム固有の機能を提供しようとすると、QTは、結局のところ、万能薬ではないですが、私は最終更新日時をしていたファイルを変更（ファイルを決定するために、同期時間は、最後に変更されたので、日付と時刻、合理的なので、既存のファイルの同期が）ときにそのような機能を見つけられませんでした（私はQT 3.3.4使用し、おそらく最新かつQT4がそれを提供）QTを検索しました。まさか、これはクロスプラットフォームを実現するための独自の一部だけではありません。この機能は、インターフェイスから独立して、コンパイル時のマクロは、あなたは、プラットフォームに依存しない機能を使用することができ、現在のプラットフォームを決定します。私は見つけることが、実際にWINAPI精通ハードではないですのでするSetFileTimeは、そのタイプのFILETIME、FILETIME特定の日付と時刻を直接変更することはできませんので、変数SYSTEMTIMEの定義を受け入れるようWINAPI関数と呼ばするSetFileTimeビューMSDNを設定し、使用を見出します日付と時刻、その後、SYSTEMTIME SystemTimeToFileTimeにFILETIMEタイプ、最後にするSetFileTimeを変換します。私は、おそらくいくつかの時間後に、すべてのマシンのディレクトリ同期のファイルがありませんアップデートで、安定していなければならない、私はそれが奇妙見つける、時間をデバッグの結果は常に同期の更新に保持され、それはそれだと思いました。そして、最初は論理的な問題であることを疑われるが、長い時間のためのトラックが問題を見つけられませんでした、そして最終的にするSetFileTimeすべての呼び出しのドキュメントを見つけ、修正日より私は地元の8時間は、中国はGMT + 8だと思う設定よりも。だから、MSDNを見て、私はLocalFileTimeToFileTimeもUTC時刻に現在のローカルタイムを呼び出す必要がありました。テストは再び、すべてが正常です！
次のような固有のコード：
WIN32 #ifdefの システム時刻SYSTIME。 ファイルのタイムフィート、ftUTC。 hFileをHANDLE。 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、
＆
フィート）。 LocalFileTimeToFileTime（
＆
フィート、
＆
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の
ます。https：//www.cnblogs.com/leaway/archive/2007/01/22/626437.htmlで再現