Bug #74355 [Com]: DateInterval::format() with "%F" sometimes shows incorrect value by 1us
Edit report at https://bugs.php.net/bug.php?id=74355&edit=1
ID: 74355
Comment by: for-bugs at hnw dot jp
Reported by: for-bugs at hnw dot jp
Summary: DateInterval::format() with "%F" sometimes shows
incorrect value by 1us
Status: Open
Type: Bug
Package: Date/time related
Operating System: Any
PHP Version: 7.1.3
Block user comment: N
Private report: N
New Comment:
> The floating-point inaccuracy you are describing is far below the millisecond-range. The
> fraction-issue you are pointing out here relates to a mismatch of 299 meters when you're
> calculating distances based on the speed of lightâ¦
> In GPS a timing-error of 0.0001 second results in a 0.8m offset, so for the timing error
> we're talking about here we have an offset of 8mm
>
> Is this really relevant?
It is a different topic whether there is a bug or not and whether the bug is harmful or not. Of
course you know.
In addition, this bug report also points out the asymmetry on the implementation of DateTime.
<?php
$dt1=new DateTime("2000-01-01 00:00:00");
$dt2=new DateTime("2006-01-02 03:04:05.000251");
$interval = $dt1->diff($dt2);
var_dump($interval->format("%R%Y-%M-%D %H:%I:%S.%F"));
/* Output: string(25) "+06-00-01 03:04:05.000250" */
$dt3 = $dt1->add($interval);
var_dump($dt3->format);
/* Output: string(26) "2006-01-02 03:04:05.000251" */
Datetime::format() can handle up to the last digit of microsecond. And its implementation is the
same as the patch I wrote.
This asymmetry would cause confusion.
> I'd rather say we document that it might be possible that the last digit of the fraction
> might be off by one.
Of course there is no problem as long as it is documented.
However, even #74356 points out the lack of the documentation for this implementation, there is no
response for a month.
Previous Comments:
------------------------------------------------------------------------
[2017-04-21 11:59:24] heiglandreas@php.net
The floating-point inaccuracy you are describing is far below the millisecond-range. The
fraction-issue you are pointing out here relates to a mismatch of 299 meters when you're
calculating distances based on the speed of lightâ¦
In GPS a timing-error of 0.0001 second results in a 0.8m offset, so for the timing error we're
talking about here we have an offset of 8mm
Is this really relevant?
I'd rather say we document that it might be possible that the last digit of the fraction might
be off by one.
------------------------------------------------------------------------
[2017-04-01 06:31:52] for-bugs at hnw dot jp
Another example:
<?php
$dt1=new DateTime("2000-01-01 00:00:00");
$dt2=new DateTime("2006-01-02 03:04:05.000251");
$interval = $dt1->diff($dt2);
var_dump($interval->format("%R%Y-%M-%D %H:%I:%S.%F"));
/* Output: string(25) "+06-00-01 03:04:05.000250" */
------------------------------------------------------------------------
[2017-04-01 01:35:04] for-bugs at hnw dot jp
Description:
------------
From PHP 7.1.0, DateInterval::format() supports "%F" parameter which shows fraction of
DateInterval. However, sometimes "%F" prints incorrect value because of floating point
inaccuracy.
Test script:
---------------
<?php
$dt1=new DateTime("2000-01-01 00:00:00");
$dt2=new DateTime("2006-01-02 03:04:05.524287");
$interval = $dt1->diff($dt2);
var_dump($interval->format("%R%Y-%M-%D %H:%I:%S.%F"));
Expected result:
----------------
string(25) "+06-00-01 03:04:05.524287"
Actual result:
--------------
string(25) "+06-00-01 03:04:05.524286"
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=74355&edit=1
Thread (6 messages)