[Mono-devel-list] Re: [PATCH] Various DateTime fixes and tests
swbrown at ucsd.edu
Wed Jun 9 23:07:22 EDT 2004
Atsushi Eno wrote:
>> 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
> but was:<31242239135999958>
(test line in question: AssertEquals ("Ticks-Min", 31242239136000000,
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
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)
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.
More information about the Mono-devel-list