Hey All, Hey Tim. Thanks for the feedback! On 23 Sep 2026, at 12:24, Tim Düsterhus wrote:
>> The other point I find irritating is the naming of the `Clock` interface.
>> While I can understand the reasoning behind it I see irritation in the
>> community upcoming as the `CLockInterface` now suddenly returns 2 different
>> things, depending on which ClockInterface people are talking about.
>
> While it doesn't seem to be written down as policy - but I could swear this
> topic came up on Internals at least - PHP doesn't use the `Interface` suffix
> to indicate interfaces in newly designed APIs. Following the precedent
> established by ext/random in PHP 8.2 with Random\Engine, the interface is the
> bare name and the concrete implementations sit in a sub-namespace named after
> the interface.
>
> Thus there is a clear difference in naming even for the unqualified interface
> name.
I am totally in favour of omitting the `Interface`. Still people will refer to
the `Clock` Interface and the `ClockInterface` (Hopefully never the
`ClockInterface` Interface). So - while the naming is clearly distinct also due
to the different namespaces - People *will* refer to both using the same "name".
But I do assume that very soon people will refer either to the `PHP Clock
interface` and the FIG (or PSR) ClockInterface.
>> Is there a way to Unify the ideas behind Time\Clock and
>> Psr\Clock\CLockInterface?
>
> The proposed new date/time API is a greenfield design to fix issues with the
> existing API. We deliberately don't want to “infect” the new API with ideas
> from the legacy API and returning an object carrying a timezone from a clock,
> as done in PSR-20, is the wrong design. `now()` is the obvious name for the
> method and that's why the RFC indicates that an adapter is required to
> satisfy both interfaces from the same source of truth during the migration
> phase.
>
>> As right now the Time\Clock is not a direct replacement of
>> Psr\Clock\ClockInterface as - at the current time - there is no way to
>> generate a DateTimeImmutable directly from a Time\Instant.
>
> Yesn't: You can bridge the gap by using
> DateTimeImmutable::createFromTimestamp($instant->getUnixTimestamp())->setMicrosecond(intdiv($instant->getNanoseconds(),
> 1000)).
>
> That said, I acknowledge that it's not particularly pretty and we discussed
> adding another fromInstant() constructor and ->toInstant() getter to
> DateTimeImmutable. The compatibility layer would be sitting on the old API to
> keep the new API clean.
Sounds absolutely right.
Thanks for the explanations!
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
signature.asc
Description: OpenPGP digital signature
