Now that the introductions are out of the way, it's time to start the ranting!
A customer reported today that our
JulianDate.ToDateTime method was returning a
DateTime rounded to the nearest millisecond. A little digging revealed him to be absolutely correct. This was surprising because a .NET
DateTime stores "ticks" which are 100-nanosecond intervals, considerably more precise than a millisecond.
A little more digging traced the problem to the
DateTime.AddSeconds method. Our code calls this method as part of the implementation of
The MSDN documentation for
DateTime.AddSeconds has this to say on the subject:
The value parameter is rounded to the nearest millisecond.
Well I'll be a monkey's uncle. Or something. That's certainly not what we expected. Or wanted.
So an hour later I had a new implementation of
JulianDate.ToDateTime passing my test case for this bug. The new implementation uses
AddTicks, which thankfully does not do any rounding, instead of the problematic
There's a lesson here.
DateTime is great as long as:
- You don't need to represent times more precisely than 100-nanoseconds.
- If you need to represent times more precisely than 1-millisecond, you carefully read the documentation to make sure that
DateTimeis not doing any covert rounding.
- You don't need to take leap seconds into account at all.
Of course, these limitations probably mean that DateTime is poorly suited for most aerospace and astrodynamics applications. We highly recommend that you use our
JulianDate type instead wherever possible.
At some point in the not-too-distant future, we will introduce a
GregorianDate type to Dynamic Geometry Library which will combine many of the strengths of
JulianDate and eliminate the glaring weaknesses cited above.