Surely assertTrue($expected == $date) is simpler?

Anyway, it's a floating-point issue where 0.456789 + .000001 != 0.456790
@derick can say whether this is a bug to fix or not.

As a workaround you can compare YmdHisu strings, which will have the 'u' part rounded to 6 places. https://3v4l.org/YlCDm

I'm pretty sure that this is due to floating point rounding, but perhaps there is a way to "fix" this (although I doubt it).

@derick: Why are the microseconds being stored as a floating point fraction? Can we store them as integer microseconds instead? I remember seeing some other bug reports also relating to float precision issues with the microseconds.

@requinix yes, sure. However, this is so because it's how PHPUnit handles DateTime comparison, and how I came up with this issue.

A better workaround for those facing the same issue:

// 1000000 microseconds (1 second):
// https://bugs.php.net/bug.php?id=74885
// @todo Remove it when this bug get fixed
$microseconds = $this->microseconds % 1000000;
$seconds = intval($this->microseconds / 1000000);

return $date->modify(
    sprintf('%d seconds %d microseconds', $seconds, $microseconds)
);

That may work for your example but it does not work in the general case.
https://3v4l.org/c54Dt

The problem is not in how the DateTime is modified but in how it is compared. Specifically, in how the microseconds values are compared. As things stand, if you require microsecond-level precision then you must use your own custom comparison strategy.

I can't understand why it's internally stored as float, neither why DateInverval exposes the `f` property as float, once microseconds cannot be expressed as a fraction in PHP.

Because most of the code supporting DateTime is actually a library.
https://github.com/derickr/timelib

If you missed it, @nikic had just asked @derick about why microseconds are floating-point, so let's step back and let them work.

@nikic - Why? That's a good question that I don't have an answer to. The problem with changing it now is that it is an API break in the library :-/

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

This is fixed for PHP 7.2(beta3):

derick@singlemalt:~ $ php -v
PHP 7.2.0beta3 (cli) (built: Aug 17 2017 09:57:54) ( NTS DEBUG )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies

[PHP: 7.2.0-beta3] derick@singlemalt:~ $ cat /tmp/74885.phpt 
<?php
$expected = new DateTimeImmutable('2015-08-31 01:02:04.456790');
$date = (new DateTimeImmutable('2015-08-31 01:02:03.456789'))->modify('+1000001 microseconds');

// Expected false, but it's actually true
var_dump($expected > $date || $expected < $date);
?>

[PHP: 7.2.0-beta3] derick@singlemalt:~ $ php /tmp/74885.phpt
bool(false)


As I said before, it breaks API/ABI for existing PHP versions, so it won't be fixed there.