Incompatibility with Numericality from v3.3.* to v3.4.2

[mbrostami]

Expected and Actual Behavior

Validating string '123,123' by Numericality validator is true in Phalcon v3.3.2 but is false in v3.4.2.

Provide minimal script to reproduce the issue

$validator = new Numericality();
$validation = new Validation();
$validation->add('km', $validator);
var_dump($validation->validate(['km' => '123,123']));
die;

This is the line which is changed (!is_numeric(value) has been added in v3.4.x):
https://github.com/phalcon/cphalcon/blob/3.4.x/phalcon/validation/validator/numericality.zep#L74

[Jeckerson]

#13450

In this issue problem is resolved with correcting setlocale(), which make sense. Because default behavior of is_numeric() is validate only float number with . and not with ,.

[joeyhub]

You should at all costs in PHP be avoiding anything to do with setlocale, that's for under the hood and a legacy horror that'll break a lot of things. You should never change it or rely on it. Instead use an appropriate library for intl. intl is the standard which should be used in place of the inbuilt PHP functions, however it's a bit bulky, when I last used it some message formats segfault and I'm not sure if it handles input as well as output.

PSR-joeyhub which supercedes all numeric PSRs and is the final PSR in the series almost entirely forbids the use of setlocale which must be locked to an appropriate system default (IE, C.utf8) as opposed to localised. Same as time, time must be UTC and instead DateTime used for converting to other timezones on input/output.

Take a look here:

https://www.php.net/manual/en/class.numberformatter.php

construct, format and parse are all good.

[mbrostami]

#13450

In this issue problem is resolved with correcting setlocale(), which make sense. Because default behavior of is_numeric() is validate only float number with . and not with ,.

Agree with that, but if Phalcon follows semantic versioning, then v3.4.x should not break v3.3.x functionality. I mean it could be fixed in v4.x.x.

[niden]

Resolved in #14085