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

[Steven Brown]

Atsushi Eno wrote:
> Hello,
> 
>> What's the status of the DateTime patch and the regression tests?  
>> They don't seem to be in the CVS yet; just checking to be sure they 
>> don't slip through the cracks.
> 
> 
> Oh, sorry. I thought the patch was already in.
> 
> Ok, I manually applied your fixes to the current DateTime.cs as the 
> patch attacheed. However, FromOADate test (recently Sebastien added
> it) shows that this patch is incomplete. Well, that might be my
> manual patchy wrong, but can you try make run-test in corlib and
> check if it does not happen to your box?
> 
> 9) MonoTests.System.DateTimeTest.FromOADate : Ticks-Min
>         expected:<31242239136000000>
>          but was:<31242239135999958>

(test line in question: AssertEquals ("Ticks-Min", 31242239136000000, 
DateTime.FromOADate (-657434.999d).Ticks))

This isn't a bug in my patch, it's an artifact in FromOADate exposed by 
removing the rounding to milliseconds in AddMilliseconds in my patch.  I 
say artifact rather than bug as it's not apparent from the MSDN pages 
that FromOADate is supposed to do rounding, but it surely is in 
Microsoft's implementation.

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:

((60 * 60) * 0.999) - ((60 * 60) * 0.998999999952502)
.000000170992800

If I've done my math right, that's 171 nanoseconds, or about 2 ticks. 
As such, it'd be impossible for a proper implementation to arrive at 
31242239136000000, which has zero in the ticks place, even if it was 
perfectly accurate.  Since Microsoft's does, it's probably rounding even 
though the MSDN page doesn't seem to say anything about rounding. 
Either that, or it's just a coincidence of compounded rounding error.