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 reverts commit ac34648cf6.
As pointed out on GH-6783, the new format doesn't match any of
the specified formats. Previously the constant generated
Thursday, 14-Jul-2005 22:30:41 BST
which is obsolete. Now it generates
Thu, 14-Jul-2005 22:30:41 BST
which is not specified at all. The correct version would be:
Thu, 14 Jul 2005 22:30:41 BST
Reverting the change for now.
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).
Some extensions try to use the date features in their own shutdown,
most notably some logging functions. Because of that, move the
cache tear down until after these resources have been cleaned up.
