`number_format` no longer round properly big float

[kylekatarnls]

Description

The following code:

<?php

echo number_format(1599828571.23561241, 6, '.', '');

Resulted in this output:

1599828571.235613

But I expected this output instead:

1599828571.235612

This is the result with PHP < 8.4 and it sounds good to me either we consider round() or floor() as the best operation to use.

Context: precision matters in my case, as I aim to support float timestamp (possibly more precise than microseconds) then to round them as close as possible and in a consistent manner.

PHP Version

8.4 (master 2024-05-26)

Operating System

Both Ubuntu and Windows

[devnexen]

Seems the affecting commit is this one. cc @SakiTakamachi

[SakiTakamachi]

This is not a bug. This change in behavior occurs because the precision that can be rounded has increased by one digit.

It may seem odd to round 124 to 13, but 1599828571.23561241 and 1599828571.23561251 are the same value, so they are interpreted as 125.
https://3v4l.org/DJV35

Floating point numbers are not very accurate.

(edit)

In Carbon this may not be useful, but if you can handle the value as a string from the start, you can use bcround from BCMath as of 8.4.

[kylekatarnls]

Thank you. I see, we can deal with that.

For the record, the new method DateTime::createFromTimestamp accepts float but not string which leads to loosing the precision:

var_dump(DateTime::createFromTimestamp('1599828571.235612')); // => ...235611
var_dump(DateTime::createFromTimestamp(1599828571.235612)); // => ...235611

Or to an error when using declare(strict_types=1);

In Carbon we already have createFromTimestamp and it supports string without casting it to float, on the opposite, we use number_format to cast float to string then we split second and microseconds from the string so to keep maximum precision. Result then is equivalent to createFromFormat('U.u', ...)

If float cannot fully handle precision of U.u format, then maybe createFromTimestamp should also support string.

At the moment we use round() in our createFromTimestamp implementation so that so if we take a 6-digits decimal part:

echo number_format(1599828571.235612, 8, '.', '');

Then we get: 1599828571.23561192 and 23561192 got rounded to 235612 so we actually get more chance to get closer to the initial value. (If rounding decimal part hit 1'000'000, then we just increment the second.)

For instance if we exchange this number via JSON

JSON.stringify({created_at: 1599828571.235612})

JSON can properly represent this number with 6-digit, but we get in PHP a double(1599828571.23561192) and so choosing to use floor() to read it as a timestamp will always (except 1 lucky time over 1000) lead to be off by 1 microsecond.

I'm now wondering if I should align createFromTimestamp with PHP 8.4 behavior or if the exact behavior of this new method can still be challenged.

[SakiTakamachi]

Due to the mechanism of floating point numbers, once a certain precision is exceeded, it becomes impossible to maintain the precision. In PHP, the maximum precision that can be maintained is defined by the constant PHP_FLOAT_DIG, which is 15 in general environments.

In this issue, we need up to 16 digits of precision, so float is unstable.

Luckily, this is an unreleased feature and not from an RFC, so there may be room to add a string to the argument.

[mvorisek]

IMO this is a bug - repro https://3v4l.org/V47rI

The var_dump always prints the "full IEEE 754 64b precision" and it prints xxx.xxx6124 thus the rounded result should be really xxx.xxx612.

[SakiTakamachi]

No, this is not a bug. These behaviors are clearly defined in the RFC.

https://wiki.php.net/rfc/change_the_edge_case_of_round