为什么DateTime 的最小分辨率基于 Ticks（100 纳秒单位）而不是毫秒？
【问题讨论】：
DateTime 的精度限制为毫秒（一系列缺点，例如，您要么为TimeSpan 使用不同的单位，要么不能让StopWatch 返回TimeSpan s) 什么时候可以有 100ns 的精度而没有缺点？
TimeSpan 和 DateTime 使用相同的 Ticks 进行操作，例如将 TimeSpan 添加到 DateTime 微不足道。更精确是好的。主要用于TimeSpan，但以上原因将其转移到DateTime。
例如StopWatch 测量短时间间隔，通常短于一毫秒。它可以返回一个TimeSpan。
在我的一个项目中，我使用TimeSpan 来处理音频样本。 100ns 已经足够短了，毫秒是不够的。
即使使用毫秒刻度，您也需要一个 Int64 来表示 DateTime。但是你浪费了大部分范围，因为 0 到 9999 之外的年份并没有真正有用。所以他们选择了尽可能小的刻度，同时允许DateTime 代表 9999 年。
大约有 261.5 个 100ns 的滴答声。由于DateTime 需要两个位用于时区相关标记，因此 100ns 滴答是适合 Int64 的最小十次方间隔。
因此，使用较长的刻度会降低精度，而不会获得任何收益。使用较短的刻度不适合 64 位。 => 100ns 是给定约束的最佳值。
【讨论】：
int 或 uint，即使没有使用两位来表示“时间”信息，您也只能表示少于 50 天（@987654336 @) 毫秒分辨率。如果你想为此使用一个 32 位整数，你可以使用 seconds 作为你的“tick”大小，而不是毫秒，这实际上是在所谓的“Unix time”中完成的。他们仍然会遇到问题，因为他们只使用 32 位。
DateTime 来存储 1-1-0001 或 12-31-9999 等标记值，因为实际日期似乎很危险，因为它们有多种方式可以翻译成线性日期。
用于更高的时间分辨率，即使您大部分时间都不需要它。
【讨论】：
仅供参考：
1 毫秒 = 10 000 个滴答声
1 秒 = 10 000 000 个滴答声
使用两个刻度的差异（增量）可以获得更精细的精度（稍后将它们转换为毫秒或秒）
在 C# DateTime 上下文中，刻度从 0 (DateTime.MinValue.Ticks) 开始直到 DateTime.MaxValue.Ticks
new DateTime(0) //numbers between 0 and (864*10^9-1) produces same date 01/01/0001
new DateTime(DateTime.MaxValue.Ticks) //MaxValue tick generates 12/31/9999
系统时间滴答每天增加 8640 亿滴答。
【讨论】：
tick 是系统时钟的工作方式。
【讨论】：