当然做这个对时软件，有一个多月了，有些问题一直很让人无奈，好了先说问题：先从功能说起：主要实现客户端和服务器的时间同步，其中用到了四个时间戳，T1，T2，T3，T4四个时间戳均为16进制的整数，1，[size=font-size: 7pt,7pt][font='Times New Roman'] 客户端向服务器发送对时请求，QDateTime Epoch(QDate(1900, 1, 1));
QDateTime unixStart(QDate(1970, 1, 1));
DWORD m_dif1 = GetTickCount();
QTime m_qTime;
m_qTime.restart();
m_qCurrentDateTime= QDateTime::currentDateTime();
m_secnd = quint32(Epoch.secsTo(m_qCurrentDateTime_send));//秒数qint32 mSecond=m_MsToNTP[m_qCurrentDateTime_send.time().msec()];//当前毫秒数比如当前的时间为2012-08-01 14:26:31 ，其中毫秒为 113ms,那么m_secnd表示为16进制为D3 C3 4A 98 ,将毫秒113乘以0xffffffff得到数值为0x1CED9168那么在UDP数据包中T1的数值就是D3 C3 4A 98 1C ED 91 68把T1包装为UDP数据发送给服务器，2，[size=font-size: 7pt,7pt][font='Times New Roman'] 服务器收到数据，向客户端发送数据比如，服务器通过UDP数据包发回的T2数据为D3 C349 82 56 C8 B4 39，T3也是D3 C3 4982 56 C8 B4 39，那么我在有数据报时，取当前的系统时间为2012-08-01 14:26:32其中毫秒数为113ms，将T2 和T3倒算成quint64数据nT4然后QDateTime time_t.setTime_t(nT4- Epoch.secsTo(unixStart)); time_t的日期为2012-08-01 14:26:54秒，其中毫秒数为339ms也就是T2日期为2012-08-01 14:26:54秒，其中毫秒数为339msT3也是2012-08-01 14:26:54秒，其中毫秒数为339ms在此时客户端取当前时间为2012-08-01 14:26:32其中毫秒为 113ms,由此时间生成的T4为D3 C34A 98 1C ED 91 68T1在数据包中，在服务器发送的数据包中没有改变依然是发送时的D3 C3 4A 98 1C ED 91 68，根据这个数值计算为时间为2012-08-01 14:26:32 ，其中毫秒为 113ms, 问题也就出来了： 问题1，T1时发送对时请求时的时间，T4为收到服务器相应后的本地时间，T1在前，T4在后，其中是包含网络延时的，但是T1和T4从数值上1ms 都不差，所以是有问题的，而且T1和T4为不同的时刻所取得系统时间，所以绝对不可能从数值上1ms不差，即使是同一级交换机，网络延时也是大于1ms 的。我用以下这种方法计算T1事件到T4事件的延时：均为UDP通讯QTime m_qTime;
在T1中intnDiff1 = m_qTime.restart();
在T4钟int nDiff2=
m_qTime.elapsed();
但是这两个数值相减始终为0，也就是说程自己计算的T1事件到T4事件的延时为0。 问题2，T1实际的发送时间为2012-08-0114:26:31 ，毫秒为 113ms, T1的数值就是D3 C3 4A 98 1C ED 91 68，经过服务器之后，T1 D3 C3 4A 98 1C ED 91 68T2 D3 C3 49 82 56 C8 B439T3 D3 C3 49 82 56 C8 B439根据数据包中T1的数值解算的时间为2012-08-01 14:26:32毫秒为 113ms,也就是说比实际的时间多1s，也就是说数值经过QDateTime time_t.setTime_t(nT4- Epoch.secsTo(unixStart)); 这种算法比原来多了1s，如果说这种算法在解算时间上有问题那么解出来的T2和T3时间也就同样会存在问题。
