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.
These tests fail with the following diff:
========DIFF========
date: Tuesday, July 7, 2009 8:41:13 PM EDT
002+ msgf: Wednesday, July 8, 2009 12:41:13 AM utc
002- msgf: Tuesday, July 7, 2009 8:41:13 PM usnyc
========DONE========
FAIL Bug #58756: w.r.t MessageFormatter [ext/intl/tests/bug58756_MessageFormatter_variant2.phpt]
========DIFF========
001+ quinta-feira, 17 de maio de 2012 4:35:36 da tarde utc
001- quinta-feira, 17 de maio de 2012 5:35:36 da tarde ptlis
========DONE========
FAIL MessageFormat accepts IntlCalendar args [ext/intl/tests/msgfmt_format_intlcalendar_variant4.phpt]
That is, it appears that the timezone does not get applied. I don't
know why this happens, and don't want to spend more time trying to
figure this out.
Before the zval -> zend_object migration, this code used macros
like FORMATTER_METHOD_FETCH_OBJECT_NO_CHECK, which internally
clear the error. Now that they are no longer used, we need to
manually clear the error.
Default them to IntlDateFormatter:FULL, which has value 0, which
was what you would get if you passed null to these arguments in
weak typing mode. The documentation called this ICU's default
date/time type.
This deprecates passing null to non-nullable scale arguments of
internal functions, with the eventual goal of making the behavior
consistent with userland functions, where null is never accepted
for non-nullable arguments.
This change is expected to cause quite a lot of fallout. In most
cases, calling code should be adjusted to avoid passing null. In
some cases, PHP should be adjusted to make some function arguments
nullable. I have already fixed a number of functions before landing
this, but feel free to file a bug if you encounter a function that
doesn't accept null, but probably should. (The rule of thumb for
this to be applicable is that the function must have special behavior
for 0 or "", which is distinct from the natural behavior of the
parameter.)
RFC: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
Closes GH-6475.
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.
Make the behavior of substr(), mb_substr(), iconv_substr() and
grapheme_substr() consistent when it comes to the handling of
out of bounds offsets. substr() will now always clamp out of
bounds offsets to the string boundary. Cases that previously
returned false will now return an empty string. This means that
substr() itself *always* returns a string now (like mb_substr()
already did before.)
Closes GH-6182.