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.
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.
Saw a spurious failure from this one on azure macos, presumably
the process got interrupted in the middle and waited for more than
one second to resume.
After looking a bit more closely, this test doesn't actually test
what bug #48187 reported, because there is no DateTime::diff()
anywhere to be found. This test was also added speculatively,
because the root cause was never diagnosed, and the problems seems
to have resolved itself at some point.
As such, I'm simply dropping this test, rather than figuring out
how to make it more robust.
Since `DateTimeZone` does not implement a `compare_objects` handler,
nor has any properties, two `DateTimeZone` instances always compare as
being equal, even if they designate totally different timezones. Even
worse, after calling `var_dump()` on these objects, the actual
comparison may yield a correct result.
We therefore introduce a `compare_objects` handlers, which prevents
different behavior before/after `var_dump()`, and which allows us to
clearly define the intended semantics.
We check that the given microsecond fraction is in the valid range
[0, 1000000[, and otherwise mark it as invalid. We also drop the
useless do loop; a plain block is sufficient here.
When getting the properties of a DatePeriod instance we have to retain
the proper classes, and when restoring a DatePeriod instance we have to
cater to DateTimeImmutable instances as well.
Arbitrary DateInterval objects don't have well-defined comparison
semantics. Throw a warning and treat the objects as uncomparable.
Support for comparing DateInterval objects returned by
DateTime::diff() may be added in the future.
- [date_timestamp_get] adding coverage for date_timestamp_get alias to
DateTime::getTimestamp feature at PHPRio TestFest
- [date_timestamp_get] adding coverage for date_timestamp_get basic
feature at PHPRio TestFest
- Combine tests into single file
Function strftime is part of the C89 standard [1] and current systems
don't need to check for its presence anymore.
Additionally, checks for strftime function in tests have been removed
since the PHP strftime function is now always available.
1: https://port70.net/~nsz/c/c89/c89-draft.html
