Question

Eric Lippert wrote an article about DateTime. Jon Skeet commented on his article with

I don’t have a problem with DateTime having too much precision so long as everyone knows it. Precision, not accuracy

What does he mean by that?

What does it mean to approach DateTime precision issues, vs. accuracy issues?

Answer 1

He’s using the term accuracy wrong in that article. Poor accuracy really implies a systematic bias, such as what would happen if your computer’s clock were off by one minute. What Lippert’s article is really illustrating is false precision.

In other words, the DateTime structure is very precise in that it is capable of representing a difference of only 100 nanoseconds. However, the values you’ll get from DateTime.Now are only precise to within 16 milliseconds. But the numbers you’re given will still carry the full precision that DateTime is capable of representing. That creates a gotcha, since it’s easy to assume that DateTime.Now is returning values that carry the DateTime structure’s full precision instead of taking the time to find out what precision is provided by the source from which DateTime.Now gets its values.

DateTime, being a simple data structure, has no inherent accuracy, so it doesn’t really make sense to talk about it. (What’s the accuracy of a kilogram?) Better to talk about how accurate the system clock is. (e.g., how accurate is that scale?) But that could vary with every computer, and doesn’t really have anything to do with data structures in .NET.