Hi Dan,
I think you make some bad assumptions here. The examples provided by
Sjon are scripts submitted to 3v4l.org They may have bad assumptions,
but are real life examples of DateTime usage. And they will break.
We have two issues in our codebase. We ARE testing RC release, I think
feedback should be taken seriously.
1. We overloaded DateTime::setTime, this needed an update because of the
extra parameter (point 3). BC break.
2. We test the following:
A. $date = new DateTime;
B. Store in database.
C. Retrieve datetime.
D. $fromDatabase = new DateTime(storedDateTime);
E. $fromDatabase == $date (which fails now, because $date has
microsecond precision while $fromDatabase doesn't).
Where does this have a bad assumption? We tested an assumption (DateTime
has seconds precision), and now it fails. Is that a bad assumption? I
think it's just backward breaking with no good way to fix the code.
We could set microseconds to 0, which is cumbersome because of a missing
setMicroseconds method. One needs to call setTime with retrieved hours,
minutes, seconds or setTimestamp($dt->format('U'))...
"Rely only on reliable things."...
Arjen
On 11/08/2016 12:03 PM, Dan Ackroyd wrote:
On 8 November 2016 at 09:32, Arjen Schol <ar...@parse.nl> wrote:
Hi,
Support for microseconds was added late in the 7.1 RC cycle, however is has
some issues:
My understanding is that if this affects your code, then your code
already has a bad assumption in it. The code is mistakenly assuming
that two DateTime's generated will have the same the same time for
both of them.*
I don't fully understand what problem you are want to solve through
this discussion. No-one is forcing you to update to PHP 7.1
immediately; you should have plenty of time to fix the code that has
bad assumptions about the time in a generated DateTime before you
upgrade to PHP 7.1.
SjonHortensius wrote:
if generating a DateTime takes roughly 4 μs (which it does for me), this
happens ~ 250.000 times
more often
Having bugs happen more frequently is a good thing. It stops you from
ignoring edge cases and programming by coincidence.**
I realise that having a release make it more obvious that broken code
is broken is an annoying thing to have to fix....but that code is
already wrong. Delaying useful features, just to avoid having to fix
flaky code is not a good way for a project to proceed, imo.
dshafik wrote:
I think default microseconds to 0 when unspecific for relative strings is
correct behavior
I don't think that sounds like a good plan at all. When creating a
DateTime through `new DateTime('first day of next month');` only the
date values are set from the input string, the rest of the time is set
to now().
Wouldn't having microseconds behave differently to the rest of the
time values would be instantly an extra piece of inconsistency for
people to regret?
cheers
Dan
* Example code that doesn't work correctly now. If the sleep period is
reduced, it becomes less obvious that the code is broken, but it is
still broken.
for ($i=0; $i<10; $i++) {
$dt1 = new DateTime('first day of next month');
usleep(rand(0, 500000));
$dt2 = new DateTime('first day of next month');
if ($dt1 == $dt2) {
echo "Same\n";
}
else {
echo "Different\n";
}
}
** Programming by Coincidence -
https://pragprog.com/the-pragmatic-programmer/extracts/coincidence
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
