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

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:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc