Re: [RFC] Time\Instant and Time\Clock

Hi On 2026-10-06 18:56, Mirco Babin wrote:

(Mirco Babin) There is a misconception. The application does not choose the abstracted clock truth for the Composer installed libraries. It only chooses the clock for its internal parts. Each piece of software, internal application and each different external library, chooses its own source of abstracted clock truth, like:

Of course. If the library provides no way to inject a clock, then you can't inject a clock. What I meant to say is that if the libraries you use allow injecting a clock (e.g. PSR-20 or the new Time\Clock, or something else of course), then you can use the adapters to translate between the different interfaces, while having a single “canonical” clock as a source of truth. If the library doesn't allow injecting a clock right now, then the introduction of the new interface is no worse than the status quo.

(Mirco Babin) Every effort, however small, however little, that eases this migration path for applications, should be provided. Also because Packagist https://packagist.org/packages/psr/clock shows *439 458 545* (439 million) installations of the PSR-20 clock. This is an *impure number*, because it also includes CI/test installations, and it also includes nesbot/carbon and laravel/framework installations. *I agree to disagree.*

I'm happy to leave it at “agree to disagree”. I nevertheless thank you for raising your concern here.

Can the RFC be updated? Under rejected features can something be added like: A hybrid clock, both implementing \Time\Clock from this RFC and the PSR-20 \Psr\Clock\ClockInterface is rejected. Because ...(reasons)...

I have added a short note to the rejected features section. For the full reasoning readers can read the mailing list discussion (linked at the top of the RFC). This also avoids accidentally misrepresenting the nuance provided in the discussion due to a lack of context. Best regards Tim Düsterhus