[Mono-devel-list] Re: [PATCH] Various DateTime fixes and tests

[Steven Brown]

Atsushi Eno wrote:
> Hello,
> 
>> The problem is that IEEE floating point numbers are evil. :)  As a 
>> double, the -657434.999 argument is actually 
>> -657434.998999999952502...  Using bc, since it's arbitrary precision, 
>> we can tell what the error would be just on the fractional part (of an 
>> hour) given to FromOADate alone:
> 
> 
> Yeah, I think you're right. I thought that "implementation by double"
> might not be always a good idea. How do you think if it is reimplemented
> using decimal? (sorry, am not spending my time to implement in my box
> before just asking. It's value idea without examining in depth)

Wouldn't matter; the method's signature is defined as taking a double, 
so there's no way to avoid it getting that -657434.998999999952502.. 
number.  It's the value as given.  Even if Mono's implementation of 
FromOADate was 100% accurate (say it was implemented with GNU mp), it 
would have gotten (truncated, of course):

599264352000000000 + (-657434 * 86400000 * 10000) + (0.998999999952502 * 
86400000 * 10000)
31242239135999958.961728000000000

Casting to long, that's the exact same number as Mono currently gets for 
that test. :)

Since Microsoft's answer isn't accurate (31242239136000000), their 
implementation of the method is surely rounding at some digit place. 
That accuracy loss appears to be an undocumented 'feature', and I doubt 
it hurts Mono to leave the implementation as-is and do better than 
Microsoft in this case.