Bug #17079 [Com]: setlocale changes the internal representation of floats
| From: | schindler dot andor at empo dot deletethis dot hu | Date: | Fri, 22 Jun 2012 11:05:53 +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-171441@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: schindler dot andor at empo dot deletethis dot hu
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:
Yes, this is not a bug. This is a huge epic fail. This is a great example, why people hate PHP.
Previous Comments:
------------------------------------------------------------------------
[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!
------------------------------------------------------------------------
[2003-01-02 10:13:59] 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
------------------------------------------------------------------------
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