php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54538 setlocale() interferes with NumberFormatter class
Submitted: 2011-04-15 13:32 UTC Modified: 2018-10-09 11:01 UTC
Votes:13
Avg. Score:4.5 ± 1.2
Reproduced:11 of 12 (91.7%)
Same Version:1 (9.1%)
Same OS:2 (18.2%)
From: davidkarlin at gmail dot com Assigned: cmb (profile)
Status: Not a bug Package: intl (PECL)
PHP Version: 5.3.6 OS: OS X
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: davidkarlin at gmail dot com
New email:
PHP Version: OS:

 

 [2011-04-15 13:32 UTC] davidkarlin at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/class.numberformatter
---
When I have my locale set to 'en' with setlocale(), the NumberFormatter class 
works just fine.

If I set the locale to, for example, 'fr_FR', the NumberFormatter class fails, 
giving a 'NaN' result. This is irrespective of the fact that the setlocale() 
function has clearly worked, as evidenced by gettext() working just fine.

I can't see any reason why the setlocale function should have anything to do with 
the operation of NumberFormatter: this isn't documented, and I'm explicitly 
passing the locale I want to use in the parameter.

Using 5.3.5 (the most recent available through MacPorts)

Test script:
---------------
setlocale(LC_ALL, 'en');
$nf = new NumberFormatter('de_DE',NumberFormatter::DECIMAL);
print $nf->format(123456.789);	// Outputs the correct answer 123.456,789 
print "<br/>\n";
setlocale(LC_ALL, 'fr_FR');	
$nf = new NumberFormatter('de_DE',NumberFormatter::DECIMAL);
print $nf->format(123456.789); // Outputs NaN

Expected result:
----------------
123456.789<br/>
123456.789

Actual result:
--------------
123456.789<br/>
NaN

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-04-15 13:34 UTC] davidkarlin at gmail dot com
Sorry - I typed the wrong lines in the expected and actual results. Should be 
"123.456,789" in both cases. But you get the idea...
 [2011-04-16 16:52 UTC] cataphract@php.net
PHP passes the correct value to ICU, namely it passes the expected double to unum_formatDouble. This is likely an ICU defect. See:

http://bugs.icu-project.org/trac/ticket/8214
 [2011-07-26 13:01 UTC] radek dot dvorak at gmail dot com
I have observed a workaround. Setting LC_MESSAGES does not affect NumberFormatter
and is sufficient for gettext translations at the same time.
 [2013-05-16 19:29 UTC] hariombalhara at gmail dot com
thanks for the workaround. It worked well for me :) Here is the exact problem I 
was facing 
http://stackoverflow.com/questions/16334752/numberformatterformatcurrency-return-
nan-with-fr-fr-utf-8
 [2015-10-05 09:45 UTC] martin at tajur dot ee
This relates to https://bugs.php.net/bug.php?id=53735
 [2018-10-09 11:00 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: cmb
 [2018-10-09 11:00 UTC] cmb@php.net
This is not a PHP issue, but has rather been a bug in ICU[1],
which is resolved as of ICU 49.1.

[1] <http://bugs.icu-project.org/trac/ticket/8561>
 [2018-10-09 11:01 UTC] cmb@php.net
-Package: Unknown/Other Function +Package: intl
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 06:01:30 2024 UTC