While it may not be desired, `DateInterval::$f` supports negative
values, at least with regard to calculations. We still need to guard
from assigning double values which are out of range for signed 64bit
integers (which would be undefined behavior). zend_dval_to_lval() does
this by returning `0` instead of triggering UB. This way we can avoid
setting the invalid marker, which doesn't work as expected anyway.
We must not do that only for unserialization, but also when the property
is set in the first place.
We need to adapt some of the existing tests wrt. this behavior. In
particular, we check for an arbitrary value in bug79015.phpt, to cater
to differences between 32bit and 64bit architectures.
Closes GH-7575.
The threshold in test case ext/date/tests/bug73837.phpt has been reduced
several times, from the original 990 to current 400. However, this case
still failed on my local test with Mac Mini machine(macOS on Apple
silicon). Here is the diff result:
```
$ cat ext/date/tests/bug73837.diff
int(%d)
002+ microseconds do not differ enough (268)
002- microseconds differ
```
Hence this patch reduces the threshold further.
Note that this patch should be backported to PHP 8.1 branch as well.
Closes GH-7567.
This has been reported as bug #78984, and is generally and properly
fixed as of timelib 2020.3 (PHP-8.0). However, it is not fixed in
PHP-7.4, where the test results in an OOB read, and an unterminated
C string when calling `::getName()`. Therefore, we apply a minimal
fix which just avoids this dangerous behavior.
Fixes among others:
. Bug #79580 (date_create_from_format misses leap year).
. Bug #80974 (Wrong diff between 2 dates in different timezones).
. Bug #81097 (DateTimeZone silently falls back to UTC when providing an offset with seconds).
. Bug #81273 (Date interval calculation not correct).
These are deprecated in favor of date()/DateTime::format() (for
locale-indendent formatting) and IntlDateFormatter::format()
(for locale-dependent formatting).
Part of https://wiki.php.net/rfc/deprecations_php_8_1.
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.
Derick Rethans