为什么timepan totalmilliseconds在整数和小数部分中具有相同的数字？

Question

当计算两个DateTime对象之间的毫秒差异时,我似乎总是得到一个返回的数字,其中数字的小数部分与数字的整数分量相同.例如:1235.1235

为什么会这样？难道我做错了什么？这是语言的怪癖还是DateTime粒度的限制或其他什么？

这可以使用以下代码演示:

        DateTime then = DateTime.Now;
        Thread.Sleep(1234);
        DateTime now = DateTime.Now;
        TimeSpan taken = now - then;
        string result = taken.TotalMilliseconds.ToString(CultureInfo.InvariantCulture);
        //result = "1235.1235"

由CodesInChaos评论:

DateTime`不准确到这个精度级别:参见C#DateTime.Now precision

但是 - 这并不能解释这种行为.

Answer 1

对此有一个技术解释，我无法证明它可以解释你的观察结果。它肯定不会在我的机器上重现。

对于初学者来说，您正在寻找噪声数字，操作系统时钟不够精确，无法为您提供亚毫秒级的精度。因此，请确保您永远不会依赖他们的价值来做任何重要的事情。如果您想以高分辨率测量间隔，则必须使用秒表。

操作系统时钟受时间服务器更新的影响。大多数机器都设置为定期联系time.windows.com以重新校准时钟。这消除了时钟漂移，机器硬件通常不足以将时间精确到一个月内的一秒以上。低容差晶体价格昂贵，并且由于温度和老化效应而无法完全避免漂移。偶尔会插入闰秒，以使时钟与地球缓慢的自转保持同步。最后一个导致很多 Linux 机器崩溃，谷歌搜索“Linux 闰秒错误”以获得一些有趣的阅读。

这里重要的是当您的机器获得需要调整时钟的新更新时会发生什么。Windows 不会突然跳跃时钟值，这会导致关注时钟并期望时钟以可预测的量持续增加的程序出现重大问题。

相反，它会随着每个时钟滴答增量一次添加一点。实际上，使时钟运行得慢一点或快一点，这样它就会逐渐弥补差异并再次变得准确。也许您可以看到结果，额外增加的微秒与间隔的长度成正比。因此，在噪声数字中看到重复的间隔是合理的。

证明这一理论的唯一真正方法是调用 GetSystemTimeAdjustment()。当系统时间调整正在进行时，它将返回非零值。然后 pinvoke SetSystemTimeAdjustment() 以禁用它并观察这是否会对您看到的值产生影响。或者只是等待足够长的时间，直到时钟赶上，这样就不再进行调整。