Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2).

I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle).

I'm not sure if this helps at all, but I thought I'd add a comment anyway.

I will ask our test team to try to reproduce it.

I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem.

It seems to happen so randomly, but the only consistent element is that the numbers all have 9 in them.

There is an existing bug opened for float that was closed as bogus:
http://bugs.php.net/bug.php?id=47716

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Nothing changed here.

it's not random, it's just very hard to reproduce.  only certain specific values will trigger this bug.  and the weird thing is that the specific value changes from build to build and with different oses.

this bug is a dup of the many other existing reports about this bug.
bugs 43487, 47304, 47716, 47732, 51396  etc..

this bug has been encountered in:
php 5.2.11, 5.2.12, 5.2.13, 5.2.25, 5.2.26, 5.2.9...  

it has been found on  Windows 2000, Windows XP, Windows 2003, ubuntu, mandriva. This bug has been reproduced both with and without xdebug and/or zend debugger.


You want to reproduce this bug???!!!  it's very easy, I will give you a one-liner....

install ubuntu 8.0.4
install the standard php that comes with ubuntu 8.0.4

now run this:
echo (string) (double) -0.09999999999999999;

actual result:  -0.0:

Note that changing the float percision greatly affects the bug.

The thing is that the value is very specific to the actual build and the actual os.  For instance it was reported that on Windows nt 5.2 (2003?) the following will fail:

echo round(1451,2);

actual result: 1450.:0


It has also been reported that using BCMath helps but does not totally solve this problem "3 out of 4 were fixed".


But despite all of the above, this bug keeps getting blown off as not repro!!!  :-(


Consider the following true story:

once upon a time, there was a German insurance company sued by a client who’d lost a lot of money through the insurance company’s flawed bookkeeping. The insurance company went into a panic and started hunting the bug and were able to prove it was caused by customized software they’d bought from a German software house. They sued the software house.

The software house went into a panic and started hunting the bug further. They were able to prove the bug was actually caused by a flaw in Lotus Symphony. So they sued Lotus.

Now Lotus went into a panic and started hunting the bug further. They were able to prove the bug was actually in their C compiler. The compiler was generating a short jump when instead it should have been generating a long jump.

=======================

I first encountered this bug in a billing program that I wrote...  and so far nobody seems to give a flying fig about fixing this bug.  I do not wish to get sued by an irate customer...  especially since I am still in start-up mode and have yet to make a single nickel, otherwise I'd be willing to throw some money at php devs if that's what it took to get this fixed.  How about somebody else stepping up to the plate, there are some deep pockets out there, come on ibm, microsoft, ???   where is your community spirit?  

If there is even one single math error in php that is too much.  PHP is widely used for eCommerce $ and math accuracy is critical.  If I did not have such a huge investment in php code and skills I would have already jumped ship to a different language, as it is, I'm giving it very serious consideration.  This situation is very ungood.

Just randomly using a different version of php (the latest snapshot) does not solve anything.  It has already been established that every single version of php fails with different values.  So changing the version will cause that specific value to no longer fail.  But until the *cause* of the bug is *actually understood*...  we still have lurking failures waiting to zap us.  


Also the newer versions of php do not come with full library support, and thus *upgrades are impossible* for many of us who need/require those libraries.  Just as others have asked, I too shall ask, why is the library support missing???  When will we get it?  newer versions of php are worthless without the libraries.

I am able to reproduce this.
PHP: 5.2.13
OS: Windows 2008 Standard Server, 64-bit
(Windows NT WEB2 6.1 build 7600 from phpinfo)
CPU: AMD Opteron 6172

Using the test posted by 'adrianv at taly dot net' on bug http://bugs.php.net/bug.php?id=47418 and changing to list whole numbers, I have found the following numbers exhibit this odd behavior:
17, 19, 29, 39
and multiples of ten of these numbers (170, 1700, 17000, etc)

They get output as:
16.:0, 18.:0, 28.:0, 38.:0, etc
when using the number_format or sprintf functions to format them with decimal places.

In addition to number_format and sprintf, I have found that once you do basic math with these numbers and float numbers, even just echoing the result will trigger this bug. The bcmath functions do not exhibit this behavior.

Example:
$tot = 17;
$math = $tot * 1.5;
$math = $math / 1.5;
$math2 = bcmul($tot, 1.5, 1);
$math2 = bcdiv($math2, 1.5, 1);
echo $math //outputs 16.:, expect 17
echo $math2 //outputs 17.0, expect 17.0

A follow-up: I just created a new site on the server for other testing and the test site does not exhibit this behavior.

The test site is completely separate from the main site, but I've copied the settings exactly from the main site and am using the same PHP executable and an exact copy of the php.ini file. I've run diffs on several configuration files and cannot find any differences other than name and site paths.

With both sites running on the server, I ran the test several times on each. The main site always gives me '16.:' (wrong) and the test site always gives me '17' (correct).

I have no idea what this means, but figured it might be helpful to someone looking into this.

The solution for this bug is to use the right PHP version for Windows Server. If you use IIS then you have to install a VC9 Version. http://windows.php.net/download/

VC9 builds do not have this problem anymore and we do not support VC6 anymore.

I've created a new PHP5.3.1VC9-windows compilation with mssql and the problem has 
been solved. My PC: Windows 7 + Apache 2.2 + SQLServer2008 + (my)PHP5.3.1VC9