[2002-05-07 14:36 UTC] mfischer@php.net

This is dangerous indeed. We've had already reports about this (forgot #, or did it even only came up on php-dev@?).

Though It may sound trivial, please provide a short self-contained script showing the (mis-)behaviour.

Marking as critical for now.

 [2002-05-08 04:14 UTC] jonathan at tricolon dot com

Hi somehow it has to do with converting 'numberic'-strings to floats as the script below shows:

<?

$rate1 = 1.123;
$amount1 = 5;
$rate2 = "1.123";
$amount2 = "5";

// set locale to English to handle the floatingpoints correctly
// first calculation with floats
setlocale (LC_ALL, 'en_US');
echo "This should be correct:<br><br>";
echo $rate1." * ".$amount1." = ".($rate1*$amount1);

// second calculation with floats converted from strings
echo "<br><br>This should be correct as well:<br><br>";
echo $rate2." * ".$amount2." = ".($rate2*$amount2);


// set locale to Dutch to show misbehaviour
// first calculation with floats
setlocale (LC_ALL, 'nl_NL');
echo "<br><br>This should still be correct:<br><br>";
echo $rate1." * ".$amount1." = ".($rate1*$amount1);

// second calculation with floats converted from strings
echo "<br><br>This should be wrong:<br><br>";
echo $rate2." * ".$amount2." = ".($rate2*$amount2);

?>

Hope this shows the 'bug' correctly!

 [2002-05-23 10:44 UTC] jonathan at tricolon dot com

I didn't hear anything anymore, so I am just curious if this was picked up... Thanks, Jonathan

 [2002-10-10 11:53 UTC] iliaa@php.net

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

 [2002-12-03 07:41 UTC] flying at dom dot natm dot ru

This bug seems to be still available. ?t least i can reproduce it with 4.3.0RC2 on Windows 2000 with locale set to 'ru'. 

<?php
setlocale (LC_ALL, 'en');
echo ('1.123'*'5').'<br>';
echo ('1,123'*'5').'<br>';
setlocale (LC_ALL, 'ru');
echo ('1.123'*'5').'<br>';
echo ('1,123'*'5').'<br>';
?>

Results are:
5.615
5
5
5,615

 [2002-12-16 05:22 UTC] jonathan at tricolon dot com

As Alexander points out, the bug is still available.

 [2002-12-16 08:56 UTC] jonathan at tricolon dot com

> You should not use ',' to represent floats
> ALWAYS use '.' regardless of locale.

This is exactly the problem. When the locale is changed to Dutch the internal representation of floats is changed. The separator used is changed to ','. This behaviour is incorrect and should be fixed. Check my initial and second post for a detailed description.

Thanks,
Jonathan

 [2002-12-16 19:45 UTC] iliaa@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

If you switch to a locale where the float separator is ',' then when it comes to output the data back to the user the float decimal point will be depedant on the specified locale. Internally however it'll always be '.'.

 [2003-01-02 10:13 UTC] martin at mermaidconsulting dot com

I also ran across this problem and have been messing with it for like 3 days before i finally ran across this post. 

If you do not consider it a bug I would recommend you at least include it in the documentation and make it very clear that you cannot perform calculations using thousands-seperators based on the locale settings. 

If you have a look at the following sample you can see that user-inputs will get totally messed up in case they use thousand-seperators.

<?
setlocale(LC_NUMERIC, "en_US") ; // setting the numeric locale to
us-conventions
setlocale(LC_MONETARY, "en_US") ; // setting the monetary locale to
us-conventions

$locale_info = localeconv();
  echo "mon_decimal_point: {$locale_info["mon_decimal_point"]}<br>"; //
displays the monetary decimal point used for the locale
  echo "mon_thousands_sep: {$locale_info["mon_thousands_sep"]}<br>"; //
displays the monetary thousands seperator used for the locale
  echo "decimal_point: {$locale_info["decimal_point"]}<br>"; // displays the
decimal point used for the locale
  echo "thousands_sep: {$locale_info["thousands_sep"]}<br>"; // displays the
thousands seperator used for the locale

// defines 2 variables that should be 1000000 and 750000
$a = "1,000,000";
$b = "750,000";

print "A = $a<br>";
print "B = $b<br>";

// performing a simple calculation that illustrates how PHP handles the
numbers
print "A * 1 = " . ($a*1) . "<br>";
print "B * 1 = " . ($b*1) . "<br>";
?>

Imho there is no point in having locale settings for currencies and numeric values if you cannot use it for doing calculations.

Thanks

/Martin

 [2003-01-02 13:58 UTC] php at zeguigui dot com

I switched to PHP 4.3 (in dev only) and I saw this change in locale handling. It is not OS dependant as I have the problem with Windows XP.

In PHP < 4.3.0 I have a MySQL database with floats. To handle those floats I had to make some convertions (with str_replace) as results were not locale dependant (I use fr_FR). For instance if I had 1.234 stored in db, $row = mysql mysql_fetch_row($handle) would return in $row[0] the value "1.234" and $row[0] * 100 would return 100 whereas of 123,4 (if outputed).

In PHP = 4.3.0 I do not need those convertion routines anymore (it was a workaround in my opinion).

So starting with PHP 4.3:
$a = 1.234 ==> OK whatever locale is
$b = "1.234" ==> OK whatever locale is
$c = "1,234" ==> NOT OK whatever locale is

If I have some user inputs I have to convert from locale representation to number representation before processing them... it would be great to have a function that do the job for us (didn't find one, sorry!)... but maybe that's not the good place to ask for this!

 [2003-07-05 06:13 UTC] dMNz at one dot lt

am pabandymuj..

 [2004-10-23 16:58 UTC] erki at lap dot ttu dot ee

Having the setlocale function in string.c execute 

if ((lc.decimal_point)[0] != '.') {
	/* set locale back to C */
	setlocale(LC_NUMERIC, "C");	
}

is not a solution. The particular "fix" broke other things. In many countries, comma is used as a decimal separator. Case in point: 3 weeks ago, a certain financial database of a major telco company in Europe was upgraded to use PHP 4.3.8 (formerly 4.2.2). The system uses Oracle for persistence, where the decimal separator is a comma, as is a custom in that country. So numbers came in from Oracle, and then PHP was unable to process them correctly. For example, if a client had a debt of 25,12?, and the client paid 5?, then the comparison ($paid_amount > $debt) said incorrectly that the paid amount was more than the debt.

Result: hundreds of wasted man-hours. In the end we recompiled PHP without that "fix".

 [2012-06-22 11:05 UTC] schindler dot andor at empo dot deletethis dot hu

Yes, this is not a bug. This is a huge epic fail. This is a great example, why people hate PHP.

 [2013-07-31 09:41 UTC] philonor at googlemail dot com

Did the behavior change between 5.3 and 5.4?
I get curious values running the following script on
5.3.3 (ubuntu) and 5.4.7 (win):

<?php
	setlocale(LC_ALL, 'en_EN');
	
	$x = 0.1;
	echo $x;
	echo '<br />';

	setlocale(LC_ALL, 'de_DE');
	
	$x = 0.1;
	echo $x;
?>

5.3.3 (ubuntu) gives me the following:
0.1
0,1
5.4.7 (win):
0.1
0.1

That can't be the expected behavior if there was no change
between those versions?