The DateTime extension supports awesome modifiers like "2 days ago", "last day of this month", ... or basic ones like "+1 month".

But the last one is actually tricky: it increments the month value of the date.

For instance 2023-01-01 (January first) becomes 2023-(01+1)-01 => 2023-02-01

But as not all months last 31 days: incrementing one month on 2023-08-31 results to 2023-09-31 which doesn't exist and is thus corrected to 2023-10-01.

If you keep playing, you will notice that modify('+1 year') returns a different date than calling 12 times modify('+1 month') 🤯

(new DateTime('2023-01-31'))->modify('+1 year'); // 2024-01-31
(new DateTime('2023-01-31'))
    ->modify('+1 month') // 2023-03-03 which is the root cause
    ...
    ->modify('+1 month'); // 2024-02-03

At AssoConnect, we deal with monthly and yearly subscriptions, memberships, ... so we need reliable and predictable date operations.

The latest release of our https://github.com/assoconnect/php-date library brings a month & year traveler with 3 main features:

1. The last day of the month is sticky

   September, 30th + 1 month = October, 31st instead of 30th

2. A month is never skipped

   January, 30th + 1 month = February, 28th (or 29th) instead of March, 1st

   February, 29th + 1 year = February, 28th instead of March, 1st

3. The year-over-year result is consistent with the initial reference

   January, 30th + (1 month) x 12 = January, 30th instead of February, 2nd

We published this library under the MIT license so feel free to use it!

This obviously broke my current Adminer setup with the login-ssl.php plugin so I decided to publish a dedicated Adminer Docker image dedicated to Azure-managed MySQL servers.

This image is based on the latest official Adminer Docker image and ships with a combined certificate for both Flexible & Single servers.

The code source is available at https://github.com/assoconnect/docker-adminer-azure under the MIT license and is daily built & published to Docker Hub at https://hub.docker.com/r/assoconnect/adminer-azure

Happy admin!

But maintaining it was also too intense so we decided to migrate to the Symfony framework backed by a strong community.

We aimed to get as many end-to-end legacy-free flows as possible to lay down strong foundations to build modern code ASAP.

This means Symfony must be exposed and visible to the world: it can't start as a small piece within our old framework.

So we first changed the routing: Symfony will be from now on the entry point

• If a modern controller supports the requested route, then it serves it

• If not, then the request is routed to our legacy framework which handles it

# routes.yaml
legacy_all:
    path: /{path}
    controller: App\Controller\LegacyController::index

Running php bin/console debug:router shows that the routing rule comes last ✅

Then we established a base rule for dependency injection:

• ✅ Old code can depend on modern code

• ❌ Modern code cannot depend on old code

The container is passed along the Request object so old code can access modern dependencies through public aliases.

This makes it possible to have an end-to-end flow without a line of old code 😎

And old code doesn't stain the new code ✅

It also designs a strategy to migrate the codebase:

• Draw the dependency tree

• Start with the leaves until there is no more old code

Our proprietary ORM uses entities close to Doctrine 1 ones (they persist themselves) which is very different from the Doctrine 2 logic (the ORM is in charge of persisting entities).

Our entities also have built-in lifecycle events and validation.

So migrating overnight wasn't an option 🟥

We set a second rule for migrating entities in line with the main plan:

• ✅ Old tables can sync (create, update, delete) modern tables

• ❌ Modern tables cannot sync back to old tables

⚠️ This creates a strong constraint: a modern table (and the related entity) is read-only as long as the old table exists.

It wasn't obvious at first sight but it actually makes sense when migrating data

• You first expose a new interface (modern tables and entities).

• Then you migrate read services.

• Then you migrate write services (you should only have a few ones anyway or you have duplicate code or bad responsibilities segregation).

We are still migrating and our strategy is sometimes frustrating: rules may require us to migrate a part that is not a business priority.

But it helps to keep a clean modern codebase 💫

And it has a rewarding upside: the more code you migrate, the more code turns migratable 🤩

You followed the documentation and yet date and time don't get mocked in your tests?

Let's review how it works and the common pitfalls we know of at Springly.

How it works

The ClockMock relies on PHP name resolution rules to define date & time functions in your app namespace when you run tests annotated @time-sensitive

namespace App\Tests\Something

use PHPUnit\Framework\TestCase;
use Symfony\Component\Stopwatch\Stopwatch;

/**
 * @group time-sensitive
 */
class MyTest extends TestCase
{
    public function testSomething()
    {
        $stopwatch = new Stopwatch();

        $stopwatch->start('event_name');
        sleep(10);
        $duration = $stopwatch->stop('event_name')->getDuration();

        self::assertEquals(10000, $duration);
    }
}

The following functions are defined with the previous code block:

• App\Tests\Something\time() & App\Something\time()
• App\Tests\Something\microtime() & App\Something\microtime()
• App\Tests\Something\sleep() & App\Something\sleep()
• App\Tests\Something\usleep() & App\Something\usleep()
• App\Tests\Something\date() & App\Something\date()
• App\Tests\Something\gmdate() & App\Something\gmdate()

For the most curious, this is done in Symfony\Bridge\PhpUnit\ClockMock with an eval() call.

Common pitfalls

Use the right binary

ClockMock only works if you run your test suite with the vendor/bin/simple-phpunit binary.

Don't use Composer vendor/autoload.php or the base vendor/bin/phpunit binary when running tests. For instance, the right setup with Docker & PHPStorm is

Alternatively, you can also use this configuration to explicitly set up the right listener:

<!-- phpunit.xml.dist -->
<!-- ... -->
<listeners>
    <listener class="\Symfony\Bridge\PhpUnit\SymfonyTestsListener"/>
</listeners>

Not every time classes and functions are mocked

Only the following functions are mockable:

• time()
• microtime()
• sleep()
• usleep()
• date()
• gmdate()

The DateTime class is not mockable nor other PHP classes.

However, you can use this as a workaround:

$real = new DateTime('now');
$mocked = new DateTime('@' . time());

Fully qualified function name are not mocked

Time-based function mocking follows the PHP namespace resolutions rules so "fully qualified function calls" (e.g \time()) cannot be mocked.

Functions are mocked in a limited set of namespaces

Following the first example, the PHPUnit bridge will mock time functions in these namespaces:

• App\Something
• App\Tests\Something

Check that your time functions calls are actually done within one of these mocked namespace or call ClockMock::register(MyClass::class) beforehand.

Workaround PHP internal cache system

Newest versions of PHP cache name resolution results to improve performance as detailed in the following bug reports:

• #76788
• #64346

It means that the following test suite won't work as you expect.

namespace App\Tests\Something

use PHPUnit\Framework\TestCase;
use Symfony\Component\Stopwatch\Stopwatch;

class MyTest extends TestCase
{
    public function testSomething()
    {
        $now = time();
        self::assertTrue($now > 0);

        ClockMock::register(MyTest::class);
        ClockMock::withClockMock(0);

        // This will fail as the namespace resolution result was cached
        // by the previous call to time() 
        self::assertEquals(0, time());
    }
}

You can either use a bootstrap.php or a custom PHPUnit configuration to work around it for common used classes in your codebase (like a base Doctrine entity trait to set createdAt & updatedAt properties).

<!-- phpunit.xml.dist -->
<!-- ... -->
<listeners>
<listener class="Symfony\Bridge\PhpUnit\SymfonyTestsListener">
  <arguments>
    <array>
      <element key="time-sensitive">
        <string>App\Tests\Something</string>
      </element>
    </array>
  </arguments>
</listener>
</listeners>

or a bootstrap file:

# bootstrap.php to setup in phpunit.xml
ClockMock::register('App\\Something\\');

⚠️ Use the namespace and not the fully qualified class name. If your class is App\Something\MyClass then use App\Something in the example above and not App\Something\MyClass.

Happy testing!