So, I noticed on the is_numeric page that:

"Thus +0123.45e6 is a valid numeric value."

But can that be explained as to why that this? It breaks json_encode when 
JSON_NUMERIC_CHECK is called in certain situations. The function 
'is_numeric_string' returns the type 'double' for strings like "3e122345", and 
that isn't a double. 

My patch updated 'is_numeric_string' which might be too agressive. Maybe updating  
json.c is a better alternative.

So the new patch just updates json.c. Instead of throwing the warning and setting 
the value to 0, it makes the value a string. That way json_encode doesn't change 
a value that it possibly shouldn't.

Valid exponential notation values are converted.

php > $t = array('test' => '123343e871700');
php > var_dump(json_encode($t, JSON_NUMERIC_CHECK));
string(24) "{"test":"123343e871700"}"
php > $t = array('test' => '123343e1');
php > var_dump(json_encode($t, JSON_NUMERIC_CHECK));
string(16) "{"test":1233430}"
php > $t = array('test' => '1.03e-3');
php > var_dump(json_encode($t, JSON_NUMERIC_CHECK));
string(16) "{"test":0.00103}"

The same is true for number with leading zeros such as valid zip codes, like: 01001

json_encode with JSON_NUMERIC_CHECK will return integer: 1001

issue also appears for PHP 5.5.9-1ubuntu4.4

issue also appears for PHP 5.6.4 (cli) (built: Jan  8 2015 09:41:21) OSX

is this possible to be fixed in jsond?

It looks like a bug to me.

I comitted a fix to jsond: https://github.com/bukka/php-jsond/commit/37503cdff35733d580f289047f516a5df2e01813

I would like to wait after the jsond rfc vote and then possibly merge it to the core if no objections.

It's been fixed in 5.5, 5.6 and master

It appears that this never made its way to GitHub. That means it's not actually in most versions of PHP (including the one on php.net). I seem to be hitting this pretty extensively right now and I had assumed it was in 5.5.12.

Is it possible this happened for other bug fixes as well?

See the difference between:
http://git.php.net/?p=php-src.git;a=blob;f=NEWS;h=ee0e9869bd2d1acc02066564513efb6a39edd533;hb=refs/heads/PHP-5.5

and this file:
https://github.com/php/php-src/blob/a5864d9917357f4e68e4edb481ca7e3e71826ba7/NEWS#L1657

And the test for this made it in somehow:
https://github.com/php/php-src/blob/250938e2d35fc54161a18167b7901c5e3b574371/ext/json/tests/bug64695.phpt

http://php.net/ChangeLog-5.php

It looks like this fix also made it into PHP 7 successfully somehow in the transition.

It made it to 5.5 and up. It is in this commit

https://github.com/php/php-src/commit/591dbcabe57a32550fb73223521fa1323773628f

you can also see it in the 5.5 news file - search for JSON_NUMERIC_CHECK

https://github.com/php/php-src/blob/PHP-5.5/NEWS

The reason why you are hitting it is that many distros are bundled with json-c due to a licensing issue. I am not sure if jsonc has this fixed thought but there is no issue with this core json ext.

Alright - thank you for the clarification. Is there any concern about it not being in the changelog on php.net?

It is in the NEWS (changelog) for 5.5 as I linked:

https://github.com/php/php-src/blob/PHP-5.5/NEWS

So there is no issue...

Totally understand and I comprehended that the first time. I was saying that it isn't here at all and asking if that is something to care about: http://php.net/ChangeLog-5.php

Ah I see. Good catch! That's definitely my fault and I'm sorry for that! I have no idea why I put it to the 5.5.12 because it should go to 5.5.23 which means it didn't go to ChangeLog.

I will email Julien (5.5 RM) and ask him if it can be fixed. Thanks!

I think this just reared it's ugly head again in 5.6.20 (it works fine in 5.6.18 and 7.0.x). PHP 5.6.20-1+deb.sury.org~trusty+1, to be more exact.

It complains that Inf and NaN can't be represented in JSON, because it thinks we're dealing with a hex number I guess?

<?php

echo json_encode(["rss" => "5e879769"]);
echo "\n";
echo json_last_error();
echo "\n";
echo "\n";
echo json_encode(["rss" => "5e879769"], JSON_NUMERIC_CHECK);
echo "\n";
echo json_last_error();
echo "\n";
echo "\n";