We must not assume that `usearch_last()` gives the proper result for
negative offsets. Instead we'd need to continue to search backwards
(`usearch_previous`) until we find a proper match. However, apparently
searching backwards is broken, so we work around by searching forward
from the start of the string until we pass the `offset_pos`, and then
use the previous result.
Closes GH-7189.
GMT+00:00 is recognized by ICU, and is normalized to GMT. There are no
issues when GMT+00:00 is passed to `IntlTimeZone::createTimeZone()`,
but passing it to IntlDateFormatter::__construct() causes a failure,
since there is an additional check regarding the validity. While
checking the validity of the result of `TimeZone::createTimeZone()`[1]
is a good idea, comparing the IDs is overly restrictive. Instead we
just check that the timezone is supported by ICU.
[1] <https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1TimeZone.html#a35da0507b62754ffe5d8d59c19775cdb>
Closes GH-7190.
Rename the methods in MessageFormatAdapter to make sure they don't
clash with anything defined by icu itself, which may be a problem
if icu is linked statically.
The message patterns can be pretty complex, so reporting a generic
U_PARSE_ERROR without any additional information makes it needlessly
hard to fix erroneous patterns.
This commit makes use of the additional UParseError* parameter to
umsg_open to retrieve more details about the parse error to report that
to the user via intl_get_error_message()
Additional improve error reporting from the IntlMessage constructor.
Previously, all possible failures when calling IntlMessage::__construct()
would be masked away with a generic "Constructor failed" message.
This would include invalid patterns.
This commit makes sure that the underlying error that caused the
constructor failure is reported as part of the IntlException error
message.
Closes GH-6325.
Since we're dealing with floating point numbers, precision issues may
hit us, and actually it's not necessary to check for the exact number
anyway, because it is not exact in the first place. Therefore, we
relax the test expectations.
We have to convert to number *before* detecting the type, to cater to
internal objects implementing `cast_object`.
We also get rid of the fallback behavior of using `FORMAT_TYPE_INT32`,
because that can no longer happen; after `convert_scalar_to_number_ex`
the type is either `IS_LONG` or `IS_DOUBLE`. We cater explicitly to
the `IS_ARRAY` case what also avoids triggering a type confusion when
`::TYPE_INT64` is passed as `$type`.
I'm not totally sure, but I have a strong suspicion that the fact
that this produces an error is an artifact of undefined cast behavior
(which will yield INDVAL on x86 but saturate on ARM). INF seems to
be the only value that results in an error even on x86 (variations
like -INF or NAN succeed).
It might make sense to just remove this test entirely, but for now
let's skip it on non-x86.
RFC: https://wiki.php.net/rfc/tostring_exceptions
And convert some object to string conversion related recoverable
fatal errors into Error exceptions.
Improve exception safety of internal code performing string
conversions.
