.NET Core中的DateTime精度

本文介绍了.NET Core中的DateTime精度的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

在Eric Lippert的发布之后早于 DateTime 的精度，我在装有Windows 10的同一台计算机上的core和.NET Framework 4.5.2上运行了他的测试.

Following Eric Lippert's post years back on precision of DateTime, I ran his test on core and .NET Framework 4.5.2, on the same machine with Windows 10.

var n = 1000; int i = 0; long[] diffs = new long[n]; while (i++ < n-1) { if (ticks != DateTime.Now.Ticks) { var newTicks = DateTime.UtcNow.Ticks; var diff = newTicks - ticks; diffs[i] = diff; ticks = newTicks; } } foreach (var d in diffs) { if (d == 0) Console.WriteLine("same"); else Console.WriteLine(d); }

.NET Framework 4.5.2上的结果符合预期:输出中出现一些随机的相同"，这意味着 DateTime 在某些子级别上并不精确.

The result on .NET framework 4.5.2 was as expected: some random "same" in output which means DateTime is not precise to some sub-levels.

但是，.NET核心上的结果完全不同:输出中没有相同"的内容.不是两个 Ticks 具有相同的值.

However, the result on .NET core was totally different: no "same" in output. Not two Ticks had the same value.

解释是什么?

推荐答案

原因可能是，点网询问当前时间的底层操作系统.操作系统询问底层硬件.在远古时代，主板上的硬件时钟(RTC)用于在大约15毫秒内自我更新一次.该数字来自美国的60Hz交流电网频率，电网保持了足够的精确度.记住那是慢"的日子.计算机和设计师试图尽其所能地发挥每一点性能.因此，OS不会在有人要求时间并传递值的缓存副本时不咨询RTC －很少更新.

The explanation would be, that dot net asks the underlying operating system for the current time. The operating system asks the underlying hardware. In ancient times the hardware clock (RTC) on the motherboard used to update itself once in about 15 milli seconds. That number was derived from the 60Hz AC line frequency in US which the power grid maintained sufficient accurately. Remember those were the days of "slow" computers and designers tried to squeeze in every bit of performance they could. So the OS did not consult RTC everytime someone asked for time and passed a cached copy of the value - which is updated very infrequently.

在某些地方，主板不断发展，RTC变得更加精确.但是，操作系统及其之上的所有东西都没有必要.请记住，硬件的发展远远快于软件，甚至直到一天，消费级软件都浪费了大部分原始硬件功能.因此，当点网框架要求操作系统提供时间时，即使硬件具备了能力，它也会取回不精确的数据.准确度确实从15ms演变到1ms以下，但仅此而已.

Somewhere down the line, the motherboard evolved and the RTCs became more precise. But the OS and all the things on top of it did not feel the need for it. Remember h/w evolved far faster than software and even till day, consumer grade software waste a large fraction of raw h/w capability. So when dot net framework asked OS for time, it got back the imprecise data even when the h/w was capable. The accuracy did evolve from 15ms to below 1ms, but that was it.

来到Windows 8(服务器2012)，最终人们意识到(1)应用程序可以在更精确的时间上做得更好(2)计算机速度很快，因此每次咨询RTC不再是问题(3)大量的程序员和程序习惯于并且实际上依赖于不精确的时间行为.因此，他们(第8站)继续引入了一种新的机制，以获取最精确的时间数据，但速度稍慢一些，但是保留了原来的实现方式.

Come windows 8 (server 2012), it was finally realized that (1) applications could do better with more precise time (2) computers are fast so consulting RTC everytime is no longer a problem (3) a large population of programmers and programs are used to and actually rely on the imprecise time behavior. So they (win 8) went on to introduce a new marginally slower mechanism to obtain the most precise time data, but left the original implementation unchanged.

始终使用较旧且不精确的OS函数 GetSystemTimeAsFileTime ，并且当新的堂兄 GetSystemTimePreciseAsFileTime 出现在获胜者8中时，选择了向后兼容的方式，并且什么也没做.

Dot net had always used the older and imprecise OS function GetSystemTimeAsFileTime and when a new cousin GetSystemTimePreciseAsFileTime appeared in win 8, dot net chose to go the backward compatible way and did nothing.

点网核心是对许多核心功能的全新重写，现在利用了高精度数据源.

Dot net core is a fresh rewrite of many core features and now leverages the high precision data source.

如果当前时间是 13:14:15:123456 ，那么仍然不能保证物理学家和天文学家看到的是真实的真实时间.您的计算机不是原子钟.当然不是一个很好的同步时钟.唯一的意思是，如果两个事件在不同的时间戳发生，那么一个事件肯定在另一个事件之前发生.在较旧的计算机中，事件(例如日志，文件，数据库txns等)的生成速率较低，因此顺序事件分配相同的时间戳的可能性很小.这个新的时间系统迎合了现代高速率活动的需要，因此您可以将连续事件标记为不同的事件.对于两个非常接近的事件，总会有相同时间戳的机会.最终这是不可避免的.如果需要纳秒级的测量(为什么)，则需要使用不同的工具，例如 Stopwatch ，而不是 System.DateTime .

If the current time is 13:14:15:123456 , there is still no guarantee that the real true time, as seen by the physicists and astronomers is that. Your computer is not an atomic clock. And certainly not a well synchronized clock. The only thing it means is that if two events happened at different timestamps then one event happened certainly before the another. In older computers, rate of generation of events (ex logs, files, database txns etc) was lower and so there was low chance that sequential events would be assigned same timestamps. This new time system caters to modern high rate activities so that you can mark sequential events as different. Still for two very close events, there will always be a chance of same timestamp. That is eventually unavoidable. If you need nanosecond level measurement (why) you need different tools like Stopwatch and not System.DateTime.