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