Why is the minimum resolution of a DateTime based on Ticks (100-nanosecond units) rather than on Milliseconds?
Why is the minimum resolution of a DateTime based on Ticks (100-nanosecond units) rather
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
TimeSpanandDateTimeuse the sameTicksmaking operations like adding aTimeSpanto aDateTimetrivial.More precision is good. Mainly useful for
TimeSpan, but above reason transfers that toDateTime.For example
StopWatchmeasures short time intervals often shorter than a millisecond. It can return aTimeSpan.In one of my projects I used
TimeSpanto address audio samples. 100ns is short enough for that, milliseconds wouldn’t be.Even using milliseconds ticks you need an Int64 to represent
DateTime. But then you’re wasting most of the range, since years outside 0 to 9999 aren’t really useful. So they chose ticks as small as possible while allowingDateTimeto represent the year 9999.There are about 261.5 ticks with 100ns. Since
DateTimeneeds two bits for timezone related tagging, 100ns ticks are the smallest power-of-ten interval that fits an Int64.So using longer ticks would decrease precision, without gaining anything. Using shorter ticks wouldn’t fit 64 bits. => 100ns is the optimal value given the constraints.