PHP-Intl acts different for PHP V7.0.20 - php

Question

I have the following code:
$lang="de-AT";
$currency="3333";
$formatter = new NumberFormatter($lang, NumberFormatter::DECIMAL);
$formatter->setAttribute(NumberFormatter::MAX_FRACTION_DIGITS, 2);
echo $formatter->format($currency);
can be run in here with copy/paste:online php (though I don't know the php version of this site)
which outputs: 3.333 and is exactly what I've expected.
But on my local host with PHP 7.0.20 and PHPUnit 6.2.1 the Unit test gives me as result: 3 333.
Any idea what's new or why?

Answer 1

The difference you see here for the locales de-AT:
3.333
and
3 333
is just that with a bare string comparison, there is a difference.
For written language, there is not. Both forms are correct in that locale and show the same number.
However, you'd like to configure that more explicitly, for that, command the number-formatter to use the dot '.' as thousands separator (instead of using the compiled in locale information):
$formatter->setSymbol(NumberFormatter::GROUPING_SEPARATOR_SYMBOL, '.');
Configuration Data
The underlying cause is that the PHP intl extension next to the actual code ships with language data (from the CLDR project) which consists of the formatting information in form of symbols and rules. That means, that the formatting can change (as you found out in your Phpunit test) even if the extension version is the same. Derived from your example:
Output for hhvm-3.15.4 - 3.19.0, 7.2.0alpha1
3.333
1.1.0
Output for 5.6.0 - 5.6.30, 7.0.0 - 7.1.6
3 333
1.1.0
The line which is causing the space instead of the dot is:
http://unicode.org/cldr/trac/browser/trunk/common/main/de_AT.xml#L120 (#13494)
The concrete change:
http://unicode.org/cldr/trac/changeset/11798/trunk/common/main/de_AT.xml
Previously the number group symbol was taken over from parent locale which has the dot.
That is in Changeset 11798 Timestamp: 07/13/15 12:38:02 (2 years ago) - Releases take time, so this is why you see this only in the later releases of the library.
I can only stress the point that this is configuration data.
Dealing with Configuration in (Unit-) Tests
In a unit-test you normally don't want to test for that. In a configuration test, you might want to test for that. Your Phpunit-test did reveal that the expectation you had so far is not matched any longer. So this might require either a code-change (that is to make your configuration expectation working again) or a change in the test, as you were testing locale specific configuration you might have not been what you were looking for.
From your question I can imagine that both is possible. In the end, the test reflects your expectation and might have revealed a hidden dependency, here the locale configuration data.
A fix could be as little as switching the locale to "de" instead of "de-AT": https://3v4l.org/hB15n
Output for 5.6.0 - 5.6.30, hhvm-3.15.4 - 3.19.0, 7.0.0 - 7.2.0alpha1
3.333
1.1.0
But keep in mind that this would also hide the underlying issue that you might have tested for the wrong thing. So better keep the failing test as a note to ask yourself about the expectations you had and if the code does for what you have it written for.