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

On Sun, Oct 4, 2026, at 9:04 AM, Mirco Babin wrote: > (Mirco Babin) These adapters are not what I meant. My point concerns > all applications that currently use the PSR-20-Clock. To clarify more, > consider an application using the PSR-20 clock with a theoretical > function like this: > > ```php > <?php > // > // The original theoretical PSR-20-application > // > class MyApp_Clock implements \Psr\Clock\ClockInterface > { > public function now(): \DateTimeImmutable { > return new \DateTimeImmutable(); > } > } > > function AFunctionOfTheApplication() > { > // $clock might also come from a Dependency Injection container. > // Or be injected via parameters or via constructor injection. > // It doesn't really matter. > $clock = new MyApp_Clock(); > > // The $clock is injected into external libraries. These > // libraries are not under the control of the application. > // Also the libraries do not use the Dependency Injection > // container of the application. Otherwise the DI container > // would have beeen provided as parameter instead of the > // \Psr\Clock\ClockInterface. > $result1 = Library_Alfa_Do_Something($clock); > > $result2 = Library_Beta_Do_Something($clock); > > $result3 = Library_Gamma_Do_Something($clock); > > $result4 = Library_Theta_Do_Something($clock); > } > ?> > ``` > > At some point in the future time, one of the 4 libraries switches > to \Time\SystemClock. Let's assume it is Beta that adapts. How is this > code then going to look? > > ```php > <?php > // > // Modified theoretical PSR-20-application > // > > function AFunctionOfTheApplication() > { > // $clock might also come from a Dependency Injection container. > // Or be injected via parameters or via constructor injection. > // It doesn't really matter. > $clock = new MyApp_Clock(); > > // The $clock is injected into external libraries. These > // libraries are not under the control of the application. > // Also the libraries do not use the Dependency Injection > // container of the application. Otherwise the DI container > // would have beeen provided as parameter instead of the > // \Psr\Clock\ClockInterface. > $result1 = Library_Alfa_Do_Something($clock); > > // Or use the provided Psr20ToNative adapter. > $clockInstant = new \Time\SystemClock(); > $result2 = Library_Beta_Do_Something($clockInstant); > > $result3 = Library_Gamma_Do_Something($clock); > > $result4 = Library_Theta_Do_Something($clock); > } > ?> > ``` > > I hope the pattern becomes clear. After the \Time\Clock fact > the PSR-20-application will be split in 2 clocks. Carefully selecting > the right clock for the right call. You're setting up a pretty pathological case here. Many services using a clock, many 3rd party services using a clock, but NOT using a DI container that has even rudimentary autowiring support. Such an application is already stupidly written. A decent DI container makes this problem go away. And if you want to only have one source of time truth, you can, as Tim showed, wrap one clock around another to translate the value object. > And the careful selection has to > take place on every update of any external library. Because the > external library might have switched to \Time\Clock at any moment. > This is a maintenance disaster. This is a maintainer disaster. If they switch external dependencies that you're supposed to handle without a major version bump, you can blame the maintainer, not PHP. No different than if they switch from one HTTP client to another, etc. > This also means: Yes, I do consider all Psr's including PSR-20 > to be part of Php, and that PSR-interfaces > can't be ignored nor conflicted. > > Kind regards, > Mirco Babin As a long-time member of the PHP-FIG Core Committee, I disagree. The existing ecosystem should not be ignored, but nor should we be shackled by it. I've repeatedly said that any new http-message-object-in-core effort should NOT be bound by PSR-7, nor need it follow PSR-7; it should be good enough to *replace* PSR-7. This proposal seems like a good step to replacing PSR-20 with something even more standardized and universally available. That seems like a win in my book. --Larry Garfield