I think this is an excellent question. (I just discovered it.)
Unless you're operating with dates quite close to the year 1900, a DateTime
will have a higher precision than an OA date. But for some obscure reason, the authors of the DateTime
struct just love to truncate to the nearest whole millisecond when they convert between DateTime
and something else. Needless to say, doing this throws away a lot of precision without good reason.
Here's a work-around:
static readonly DateTime oaEpoch = new DateTime(1899, 12, 30);
public static DateTime FromOADatePrecise(double d)
{
if (!(d >= 0))
throw new ArgumentOutOfRangeException(); // NaN or negative d not supported
return oaEpoch + TimeSpan.FromTicks(Convert.ToInt64(d * TimeSpan.TicksPerDay));
}
public static double ToOADatePrecise(this DateTime dt)
{
if (dt < oaEpoch)
throw new ArgumentOutOfRangeException();
return Convert.ToDouble((dt - oaEpoch).Ticks) / TimeSpan.TicksPerDay;
}
Now, let's consider (from your question) the DateTime
given by:
var ourDT = new DateTime(634202170964319073);
// .ToSting("O") gives 2010-09-16T06:58:16.4319073
The precision of any DateTime
is 0.1 μs.
Near the date and time we're considering, the precision of an OA date is:
Math.Pow(2.0, -37.0)
days, or circa 0.6286
μs
We conclude that in this region a DateTime
is more precise than an OA date by (just over) a factor six.
Let's convert ourDT
to double
using my extension method above
double ourOADate = ourDT.ToOADatePrecise();
// .ToString("G") gives 40437.2904679619
// .ToString("R") gives 40437.290467961888
Now, if you convert ourOADate
back to a DateTime
using the static FromOADatePrecise
method above, you get
2010-09-16T06:58:16.4319072
(written with "O"
format)
Comparing with the original, we see that the loss of precision is in this case 0.1 μs. We expect the loss of precision to be within ±0.4 μs since this interval has length 0.8 μs which is comparable to the 0.6286 μs mentioned earlier.
If we go the other way, starting with a double
representing an OA date not too close to the year 1900, and first use FromOADatePrecise
, and then ToOADatePrecise
, then we get back to a double
, and because the precision of the intermediate DateTime
is superior to that of an OA date, we expect a perfect round-trip in this case. If, on the other hand, you use the BCL methods FromOADate
and ToOADate
in the same order, it is extremely improbable to get a good round-trip (unless the double
we started with has a very special form).