Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.0.3

Bug #16908 _encode() doesn't work for floats when locale is pt_BR
Submitted: 2009-12-16 00:22 UTC
From: rcmachado Assigned: alan_k
Status: Closed Package: Services_JSON (version trunk)
PHP Version: 5.1.6 OS: CentOS 5.3
Roadmaps: (Not assigned)    

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 28 - 20 = ?

 [2009-12-16 00:22 UTC] rcmachado (Rodrigo Machado)
Description: ------------ When the decimal separator is set to comma (,), what occurrs when locale is set to pt_BR (I didn't test with other locales), the parser outputs a broken JSON string. Test script: --------------- <?php setlocale(LC_ALL, 'pt_BR.UTF8'); // must have this locale installed to work $a = array( 'percent': 0.18975332068311 ); $s = new Services_JSON(); echo $s->encodeUnsafe(), "\n"; ?> Expected result: ---------------- {"percent":0.18975332068311} Actual result: -------------- {"percent":0,18975332068311} // note the "," instead of "."


 [2009-12-16 00:29 UTC] rcmachado (Rodrigo Machado)
 [2009-12-16 05:09 UTC] alan_k (Alan Knowles)
-Status: Open +Status: Feedback
Thank you for taking the time to report a problem with the package. This problem may have been already fixed by a previous change that is in the CVS of the package. Please log into CVS with: cvs -d login and check out the CVS repository of this package and upgrade cvs -d co pear/Services_JSON pear upgrade pear/Services_JSON/package2.xml or pear upgrade pear/Services_JSON/package.xml If you are able to reproduce the bug with the latest CVS, please change the status back to "Open". Again, thank you for your continued support of PEAR. Can you try SVN - I've used number format there.
 [2009-12-16 05:10 UTC] alan_k (Alan Knowles)
Well those instructions are pretty useless ;) - try here
 [2009-12-16 18:21 UTC] rcmachado (Rodrigo Machado)
-Status: Feedback +Status: Open -Package Version: 1.0.1 +Package Version: trunk
 [2009-12-16 18:26 UTC] rcmachado (Rodrigo Machado)
The number_format function doesn't resolve the problem. 1. Cast to float is the problem here. When you do this, the locale rules apply and the number stays with the comma instead of dot. 2. When you use number_format you have a (possible) loss of precision because of decimals parameter.
 [2009-12-16 18:27 UTC] rcmachado (Rodrigo Machado)
The previous submmited patch works on trunk.
 [2009-12-17 11:24 UTC] alan_k (Alan Knowles)
try now, I think this is the correct solution printf("%F", $value) - non-locale aware printing of floats.. Regards Alan
 [2009-12-18 02:19 UTC] rcmachado (Rodrigo Machado)
It works, but you have a loss of precision, even if you don't specify the precision argument. I used the following script to test: <?php $s = new Services_JSON(); $list = array( 'percent' => 0.166554584 ); echo $s->encodeUnsafe($vetor), "\n"; ?> The result was: {"percent":0.166555} Off-topic: this is weird: if I change the sprintf statement to: sprintf("%.50F", $var); The result was: {"percent":0.1665545840000000055169948609545826911926} Regards, Rodrigo Machado
 [2009-12-18 02:28 UTC] rcmachado (Rodrigo Machado)
On previous script the following line was missing (after <?php): setlocale(LC_ALL, 'pt_BR.UTF8');
 [2009-12-20 18:30 UTC] doconnor (Daniel O'Connor)
See also: Bug #16931
 [2009-12-20 19:13 UTC] alan_k (Alan Knowles)
Having looked through the PHP source I don't think there is any clean way to output the float without locale formating or loosing precision. This leaves a few options: a) use localeconv() and issue a warning or error if the decimal_seperator is not a '.' b) use setlocale() and force it to a certain local before output, and restore after. I'm tempted to do b).. Any thoughts. Regards Alan
 [2009-12-20 19:23 UTC] alan_k (Alan Knowles)
 [2009-12-21 18:18 UTC] rcmachado (Rodrigo Machado)
It works! Thanks! One more suggestion: instead of LC_ALL use LC_NUMERIC, just in case if the user has modified only the LC_NUMERIC part of locale. Thanks again! Regards, Rodrigo Machado
 [2010-01-02 09:10 UTC] alan_k (Alan Knowles)
-Status: Open +Status: Closed -Assigned To: +Assigned To: alan_k
Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at Thanks - changed it to LC_NUMERIC - hopefully that did not break anything ;)