With that in mind I'd think about - for the sake of interface segregation - removing the now function completely from the TimeInterface. The different implementations can then still implement the different interfaces in one class. And should more than one interface be required in a method we can by now require an implementation via a UnionType.

Hi Andreas,

Why would we want to remove the now method? The whole point of this component is actually to have such method.
Could you please develop?

I doubt that PSR-20 is going to be ready by the release of Symfony 6.2.

🤷 hurry up PHP-FIG :)

for the sake of interface segregation - removing the now function completely from the TimeInterface (and perhaps also moving the sleep function into a separate interface - we've discussed that during the PSR-20 discussions IIRC).

I'd better not as I explained in #46715 (comment)
If we end up being incompatible with PSR-20, we'll deal with it with a deprecation layer.
But looking at the state of PSR-20, it looks unlikely that we'll have to do that.

Thanks for the review btw @heiglandreas !

With that in mind I'd think about - for the sake of interface segregation - removing the now function completely from the TimeInterface. The different implementations can then still implement the different interfaces in one class. And should more than one interface be required in a method we can by now require an implementation via a UnionType.

Hi Andreas,

Why would we want to remove the now method? The whole point of this component is actually to have such method. Could you please develop?

The now-method would be already defined in a ClockInterface - like psr/clock or stella-maris/clock, so defining it here again in a TimeInterface is not really necessary. The actual Implementation then would implement TimeInterface, ClockInterface, SleepInterface.

So the component would either require an external ClockInterface or declare a spearate ClockInterface in parallel to the current TimeInterface and a currently not existing SleepInterface.

The now-method would be already defined in a ClockInterface - like psr/clock or stella-maris/clock, so defining it here again in a TimeInterface is not really necessary. The actual Implementation then would implement TimeInterface, ClockInterface, SleepInterface.

I want the component to be standalone and complete on its own. When PSR-20 will be ready, we might extend it, but I wouldn't make a stable PSR-20 a requirement to this component.

So the component would either require an external ClockInterface or declare a spearate ClockInterface in parallel to the current TimeInterface and a currently not existing SleepInterface.

Replying in the main thread to help readers follow the discussion: see #46715 (comment) about this topic.

Thanks for this proposal!

In the description we see this:

timeInt(): float returns the current timestamp;

I guess it's a typo that timeInt() returns a float instead of int.

If the naming of the class/methods is up for debate, here's a proposal for your consideration:

// Before
interface TimeInterface
{
    public function now(): \DateTimeImmutable;
    public function sleep(float|int $seconds): void;
    public function timeInt(): int;
    public function timeFloat(): float;
    public function timeArray(): array;
}

// After
interface ClockInterface
{
    public function now(): \DateTimeImmutable;
    public function sleep(float|int $seconds): void;
    public function timestamp(): float;
}

I'd remove timeInt(), timeFloat() and timeArray() ... but you said that they are important for performance reasons. So, why not merging all of them into a single method called timestamp() which returns a timestamp with microseconds precision. It'd be equivalent to timeFloat() ... and the timeInt() value can be obtained as (int) $clock->timestamp(). About the timeArray() method, I don't understand well its need.

Thanks.

Brain activity at night made me realize that we could remove the timeInt() and timeArray() variants and keep only time(), provided time() returns a string. As a reminder, the concern this addresses is loss-less time measurements on 32-bit archs. This is the same concern that leads to having microtime(false) also return a string.

Then I did my homework and tried to verify my own claim about performance, which is the justification I've provided for these time*() methods.

Comparing new \DateTimeImmutable('now', $tz) to microtime(true), the latter is almost 5x faster.
But when comparing new \DateTimeImmutable('now', $tz) to (string) microtime(true), the latter is only 1.1x faster!

This difference is not significant enough to warrant my claim. I'm thus removing all time*() methods from my proposal. Performance-critical time measurements might continue to use ClockMock since we can't abstract time measurements without adding overhead to it. Note that using the component for not-so-critical performance measurements is still valid, because we're talking about quite fast measurements.

Since this means the interface now contains only now() and sleep(), I've renamed it to SleepableClockInterface.

I've also implemented the offset logic @derrabus suggested for HrClock, which is now renamed MonotonicClock (because it's not "high-resolution" anymore, see notes about the overhead above.)

I updated the PR and the description above with all those changes.

I think this addresses most if not all concerns raised so far.

The last thing that remains is the lack of a ClockInterface, and that's on the PHP-FIG 🙏

I'm looking forward to the newest PSR-20 and this component! At Sylius, we've recently introduced the Calendar component, but we will surely try to migrate to the use yours. Our use case mainly decouples implementation from new in the code and provides ease-of dates testing - we need to freeze the clock and set its time for some given moment. If you are open to SettableClock implementation and interface, I would love to try it.

we need to freeze the clock and set its time for some given moment. If you are open to SettableClock implementation and interface, I would love to try it.

Sure we are if this proves needed :)

After reading php-fig/fig-standards#1257 I'm wondering if it wouldn't make sense to add withTimeZone()?

That'd allow registering only one clock service and give a contract to users to stick to a TZ.

Loosely related, I'm wondering if we shouldn't swap our approach to naming and add ClockInterface to the component. That'd be the only interface provided by the component.

The benefit of this approach is that it would make us less dependant on the outcome and pace of the FIG.

My preference goes to doing both changes I propose here: one capable ClockInterface in the component and one more specific in PSR20 when it'll be released.

PR updated with the approach proposed in my previous comment:
The component now provides a ClockInterface with 3 methods: now(), sleep() and withTimeZone().

I also registered a clock service into FrameworkBundle and a corresponding autowiring alias for ClockInterface.
Since we now have withTimeZone(), there is no need to provide several clock services (an UTC one and a default-TZ one.)

When PSR20 will be out (and if it remains compatible with the component), ppl will have the choice to use either the generic and narrow abstraction from the FIG - or the more capable one from the component when in need of extra features.

/cc @symfony/mergers even if you already voted, please vote again if you approve these changes.

Thank you @nicolas-grekas.