The bug report actually urges PHP 5.3's behavior to be
reinstated -- that is, make "\0", when used as a separator,
be the same as no separator at all. I believe that is not a
proper course of action and that "\0" being interpreted as
no seperator was a bug in PHP 5.3.
Using "" for no separator, in both 5.3 and 5.4, before and
after this change, causes no separator to be used, so
there is no functionality loss.
* PHP-5.4:
Revert NEWS
Revert "Implemented FR #61602 Allow access to name of constant used as default value"
Fix typo while resolving conflicts
Revert "Implemented FR #61602 Allow access to name of constant used as default value"
This reverts commit 054f3e3ce5.
See: http://news.php.net/php.cvs/69137 and the author confirmed.
Will commit later after the author fixed this then make a new PR.
Conflicts:
ext/reflection/php_reflection.c
I don't think the current ICU API allows this bug to be completely fixed.
Right now, the code cannot control the time zone used in date/time formats
that appear inside complex subformats. See the comment inside
umsg_set_timezone().
IntlTimeZone::fromDateTimeZone(DateTimeZone $dtz) converts from an
ext/date TimeZone to an IntlTimeZone. The conversion is done by feeding
the time zone name (essentially what would be given by
DateTimeZone::getName()) to ICU's TimeZone::createTimeZone except if it's
an offset time zone. In that case, the offset is read from the ext/date
time zone object structure and an appopriate id (of the form
GMT<+|-><HH:MM>) is given to ICU's TimeZone::createTimeZone. Not all
ext/date time zones are recognized for ICU. For instance, WEST is not.
Note that these kind of abbreviations, as far as I can tell, can only be
created via ext/date DateTime, not directly through DateTimeZone's
constructor.
For IntlTimeZone::toDateTimeZone(), the behavior is symmetrical.
We instantiate a DateTimeZone and then call its constructor if we don't
have an offset time zone, otherwise we mess with its structure. If the
timezone is not valid for ext/date, then we allow the exception of
DateTimeZone constructor to propagate.
IntlCalendar::fromDateTime(DateTime|string $dateTime[, string $locale)
intlcal_from_date_time(...)
If a string is given as the first argument, the method will try to
instantiate a new DateTime object and use that instead.
Bug#62046 mysqli@mysqlnd can't iterate over stored sets after call to
mysqli_stmt_reset().
Stmt's state was changed to STMT_PREPARED and leads the driver to think
that the stmt was just prepared. Because result set exist also for only
prepared but not executed sets, the check for stmt->result isn't any good.
There is a result set, because as response for COM_PREPARE the server sends
metadata and metadata is part of a result set. After COM_EXECUTE the server
sends metadata again, which could be different and in this case more correct.
