Conversation
ADmad
force-pushed
the
php-8.4
branch
2 times, most recently
from
d6b91c0 to
7593c47
Compare
|
The signature mismatch issue on PHP 8.4 is easily fixable but as seen from the failed tests the result of |
ADmad
force-pushed
the
php-8.4
branch
4 times, most recently
from
a7f078d to
a1fcda1
Compare
|
The change in behavior will need to be documented in the release notes. If |
ADmad
force-pushed
the
php-8.4
branch
2 times, most recently
from
3f7a71b to
ccfccdc
Compare
PHP 8.4 adds a new interface method DatetimeImmutable::createFromTimestamp().
| public static function createFromTimestamp(float|int $timestamp, DateTimeZone|string|null $timezone = null): static | ||
| { | ||
| return static::now($timezone)->setTimestamp($timestamp); | ||
| $instance = PHP_VERSION_ID >= 80400 ? parent::createFromTimestamp($timestamp) : new static('@' . $timestamp); |
There was a problem hiding this comment.
Now that we accept float, do we need to do any special rounding/etc to mimic the 8.4 behavior when converting to a @timestamp ?
I hope not. I assume they expect the timestamp to still be an integer in float format.
There was a problem hiding this comment.
I assume they expect the timestamp to still be an integer in float format.
No, the fractional part of floats is used as microseconds https://3v4l.org/OT84B#v8.1.0
We don't have to do any additional processing.
There was a problem hiding this comment.
ah, ok. Wasn't sure if the @ format would throw an error, but I think that's ok if it does.
|
I started a draft release for 3.1 with the behavior change we've inherited from PHP. |
3 participants
PHP 8.4 adds a new interface method DatetimeImmutable::createFromTimestamp().