为什么DateTime的最小分辨率基于Ticks(100纳秒为单位),而不是毫秒?
TimeSpan
和DateTime
使用相同的Ticks
,因此像将TimeSpan
添加到DateTime
这样的操作变得微不足道。更高的精度很好。主要用于TimeSpan
,但以上原因也适用于DateTime
。
例如,StopWatch
通常测量短时间间隔,通常小于一毫秒。它可以返回一个TimeSpan
。
在我的一个项目中,我使用TimeSpan
来处理音频样本。100纳秒对于此而言已经足够短了,毫秒则不行。
即使使用毫秒滴答声,您仍需要一个Int64来表示DateTime
。但是,由于超出0到9999年的年份实际上并不有用,因此您浪费了大部分范围。因此,他们选择了尽可能小的滴答声,同时允许DateTime
表示9999年。
大约有261.5个带有100ns的滴答声。由于DateTime
需要两位用于与时区相关的标记,因此100纳秒的滴答声是适合Int64的最小十进制间隔。
因此,使用更长的滴答声会降低精度而无法获得任何好处。使用更短的滴答声则不适合64位。=> 100纳秒是在约束条件下给出的最佳值。
int
或uint
,即使不使用两个位来表示“时间类型”信息,您也只能使用毫秒分辨率表示不到50天(TimeSpan.FromMilliseconds(uint.MaxValue)
)。如果要使用32位整数进行此操作,则应将_秒_用作“tick”大小,而不是毫秒,并且在所谓的“Unix时间”中实际上已经这样做了。但是,他们仍然会遇到问题,因为他们只使用了32位。 - Jeppe Stig Nielsen仅供参考:
1毫秒 = 10,000个计时周期(ticks)
1秒 = 10,000,000个计时周期(ticks)
使用两个计时周期的差值(delta),可以获得更精确的精度(后将其转换为毫秒或秒)
在C# DateTime上下文中,计时周期(ticks)从 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 亿个刻度。
滴答声是系统时钟的工作基准。
DateTime
精度限制为毫秒级别(存在很多缺陷,例如你必须使用不同的单位表示TimeSpan
,或者无法使StopWatch
返回TimeSpan
),而不是使用精度达到100纳秒却没有任何缺陷? - CodesInChaos