Bug #17079 [Com]: setlocale changes the internal representation of floats
Edit report at https://bugs.php.net/bug.php?id=17079edit=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] moriyo...@php.net
Related discussion: http://news.php.net/article.php?group=php.devarticle=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=17079edit=1
Bug #17079 [Com]: setlocale changes the internal representation of floats
Edit report at https://bugs.php.net/bug.php?id=17079edit=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] moriyo...@php.net
Related discussion: http://news.php.net/article.php?group=php.devarticle=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 100 and 75
$a = 1,000,000;
$b = 750,000;
print A = $abr;
print B = $bbr;
// 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
#17079 [Com]: setlocale changes the internal representation of floats
ID: 17079
Comment by: erki at lap dot ttu dot ee
Reported By: jonathan at tricolon dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.3.0 RC2
Assigned To: hholzgra
New Comment:
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.
Previous Comments:
[2003-07-05 06:13:19] dMNz at one dot lt
am pabandymuj..
[2003-03-24 10:18:13] [EMAIL PROTECTED]
Related discussion:
http://news.php.net/article.php?group=php.devarticle=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 100 and 75
$a = 1,000,000;
$b = 750,000;
print A = $abr;
print B = $bbr;
// 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
[2002-12-16 19:45:14] [EMAIL PROTECTED]
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
'.'.
The remainder of the
#17079 [Com]: setlocale changes the internal representation of floats
ID: 17079
Comment by: dMNz at one dot lt
Reported By: jonathan at tricolon dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.3.0 RC2
Assigned To: hholzgra
New Comment:
am pabandymuj..
Previous Comments:
[2003-03-24 10:18:13] [EMAIL PROTECTED]
Related discussion:
http://news.php.net/article.php?group=php.devarticle=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 100 and 75
$a = 1,000,000;
$b = 750,000;
print A = $abr;
print B = $bbr;
// 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
[2002-12-16 19:45:14] [EMAIL PROTECTED]
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
'.'.
[2002-12-16 08:56:08] 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
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
http://bugs.php.net/17079
--
Edit this bug report at http://bugs.php.net/?id=17079edit=1
#17079 [Com]: setlocale changes the internal representation of floats
ID: 17079
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Languages/Translation
Operating System: Red Hat Linux 7.1
PHP Version: 4.1.2
Assigned To: hholzgra
New Comment:
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
Previous Comments:
[2002-10-10 11:53:59] [EMAIL PROTECTED]
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-08-28 21:14:36] [EMAIL PROTECTED]
one more locale bug..
[2002-05-23 10:44:35] [EMAIL PROTECTED]
I didn't hear anything anymore, so I am just curious if this was picked
up... Thanks, Jonathan
[2002-05-08 04:14:04] [EMAIL PROTECTED]
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:brbr;
echo $rate1. * .$amount1. = .($rate1*$amount1);
// second calculation with floats converted from strings
echo brbrThis should be correct as well:brbr;
echo $rate2. * .$amount2. = .($rate2*$amount2);
// set locale to Dutch to show misbehaviour
// first calculation with floats
setlocale (LC_ALL, 'nl_NL');
echo brbrThis should still be correct:brbr;
echo $rate1. * .$amount1. = .($rate1*$amount1);
// second calculation with floats converted from strings
echo brbrThis should be wrong:brbr;
echo $rate2. * .$amount2. = .($rate2*$amount2);
?
Hope this shows the 'bug' correctly!
[2002-05-07 14:36:57] [EMAIL PROTECTED]
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.
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
http://bugs.php.net/17079
--
Edit this bug report at http://bugs.php.net/?id=17079edit=1
