Re: DateTime microseconds discussion

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 <arjen@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