Bug #17079 [Com]: setlocale changes the internal representation of floats

From: Date: Wed, 31 Jul 2013 09:41:01 +0000
Subject: Bug #17079 [Com]: setlocale changes the internal representation of floats
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-180621@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=17079&edit=1

 ID:                 17079
 Comment by:         philonor at googlemail dot com
 Reported by:        jonathan at tricolon dot com
 Summary:            setlocale changes the internal representation of
                     floats
 Status:             Not a bug
 Type:               Bug
 Package:            Scripting Engine problem
 Operating System:   Red Hat Linux 7.1
 PHP Version:        4.3.0 RC2
 Assigned To:        hholzgra
 Block user comment: N
 Private report:     N

 New Comment:

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?


Previous Comments:
------------------------------------------------------------------------
[2012-06-22 11:05:53] 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.

------------------------------------------------------------------------
[2004-10-23 16:58:47] 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".

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

am pabandymuj..

------------------------------------------------------------------------
[2003-03-24 10:18:13] moriyoshi@php.net

Related discussion: http://news.php.net/article.php?group=php.dev&article=95211


------------------------------------------------------------------------
[2003-01-02 13:58:52] 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!

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=17079


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=17079&edit=1


Thread (18 messages)

« previous php.bugs (#180621) next »