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

> https://wiki.php.net/rfc/time_instant_class > ========= > Comment 4 > ========= > The \Time\Clock interface conflicts with PSR-20 Clock interface, see > https://www.php-fig.org/psr/psr-20/ . A > class can never implement both > interfaces at the same time. This will hinder adoption. ... snipped ... (Tim Düsterhus) >The expectation is that you would use one of the two adapters to >translate between the PSR-20 clock and PHP’s native clock, depending >on which one is the source of truth in your application. (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: - \time() - new DateTimeImmutable() - PSR-20 \Psr\Clock\ClockInterface->now() - PSR-11 ContainerInterface->get(\Psr\Clock\ClockInterface::class) - laravel/framework exposes a \now() function. - MySql 'SELECT SYSDATE();' - MySql 'SELECT NOW();' (can be frozen with SET TIMESTAMP). - \Carbon\CarbonImmutable::now() - \Time\SystemClock::get()->now() - \Time\Clock->now() - PSR-11 ContainerInterface->get(\Time\Clock::class) etcetera. But in the end, every "abstracted clock truth" uses one singleton, one source of truth, namely the singleton system clock. (Mirco Babin) >>But because the \Time\Clock->now() conflicts, as I have demonstrated, >>with the \Psr\Clock\ClockInterface->now(), this one-time solution is >>not possible. Now assume this PSR-20-application is a big one, >>thousands of classes, millions line of code. This will become a >>PSR-20-application maintenance disaster. (Tim Düsterhus) >As Larry noted, changing from PSR-20 to the new date and time API >would be a breaking change. This kind of migration would also not >be limited to just the change in clocks. The Time\Instant, and the >modeling of the new date and time API in general are not a drop-in >replacement for the existing DateTimeImmutable API. A library that >migrates from PSR-20 to the native clock will want to consistently >use the date and time API to benefit from it. This will affect >internal calculations and possibly returned values (e.g. returning >an Instant where previously a DateTimeImmutable was returned). Just >replacing the clock and keeping everything else the same brings >little benefit. Changing the clock you pass in is the smallest part >of the migration effort. (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.* 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)... =============== End of comments =============== I have no further comments. Thank you Tim Düsterhus for considering my comments. And good luck with the RFC. Kind regards, Mirco Babin