Hello Tim Düsterhus, >> https://wiki.php.net/rfc/time_instant_class
Reply to Wed, 30 Sep 2026 19:48:51 +0000 >> ========= >> Comment 2 >> ========= >> The RFC states: >> >>> An Time\Instant carries no timezone. It represents a unique point >>> on the timeline of the universe. >> >Timezones are a concept to translate a point in time (“Instant”) into >date and time as shown on a clock. Both 2026-09-30T20:13:30+02:00 and >2026-09-30T18:13:30+00:00 refer to the same point in time. The point in >time itself does not have a timezone. The ISO-8601 getter chooses to >represent the point in time with the UTC / Zulu timezone, because >specifying an offset is required for the “date and time” representation >to be unambiguous. It would be equally valid for it to select a random >offset each time you use it. Using UTC / a zero offset is just a >pragmatic choice for best interoperability. Is this unique point on the timelime of the universe concept somewhere defined? For example in an IETF-RFC, academic paper or somewhere else? Because it seems to me that timeline of the universe must have some definition somewhere? The RFC does not have any reference to a formal definition? >> ========= >> 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. >The RFC acknowledges that. Writing an adapter is easy, particularly >since the addition of the `DateTimeImmutable::toInstant()` method to the >proposal. I have demonstrated it is impossible to write an adapter. Given the constraint that only the PSR-20 MyClock class can be changed, call-sites must not be adjusted. Also the purpose of a PSR-20 Clock is to never call `new DateTimeImmutable()` or `time()` anymore, so the assumption there are `new DateTimeImmutable()` calls that can be adapted is incorrect. >> Consider renaming the `function now(): \Time\Instant` function to >> `function nowAsInstant(): \Time\Instant`. >`now()` is the obvious name for the method. Using something else would >mean that the proposed API would still suffer from a decision made for >compatibility after everyone has migrated to it and PSR-20 is long >forgotten. The horizon we are planning with is *at least* the next 15 >years, but we're hoping that the API holds up for even longer. This is a strange point of view. Why would PSR-20 be forgotten? Is it a goal to deprecate/forget PSR-20? And why is this not mentioned in the RFC? And what would the duration be of the forget timeline? `time()` is also an obvious name for the method. And it would not conflict with PSR-20. ```php SystemClock::get()->time(); ``` >> ========= >> Comment 5 >> ========= >> The RFC introduces a SystemClock class: >> >> The RFC also states a FrozenClock for testing purposes. Well this > >The `FrozenClock` is *not* part of the RFC. It is provided in the >non-normative part of the RFC as an example to showcase how the `Clock` >interface can be useful for testing purposes. Whether or not a >`FrozenClock` will be added to PHP itself is to be decided as part of a >future RFC (by different authors, as indicated in my email from >yesterday). That is surprising. How can a SystemClock be designed without exploring the freezing of time? If the SystemClock is wrongly designed in this RFC, and hinders the unexplored, unknown FrozenTime, "*at least* the next 15 years" there will be an misdesign. I really think Time\Clock interface, SystemClock, FrozenTime, DateTimeImmutable freezing and `time()` freezing must be one RFC, that designs them very well. And don't forget the very popular Carbon library in this picture. This design should not be split between 2 RFC's and different authors. >> ========= >> Comment 6 >> ========= >> Why does \Time\Instant not have a named constructor >> `public static function fromSystemClock(): \Time\Instant` ? >> >If `SystemClock` was made a singleton >with a static getter as mentioned above (while still implementing the >interface), this would allow for: > > SystemClock::get()->now() > >for simple use cases and one-off scripts, which would be even shorter >than your proposed: > > Instant::fromSystemClock() If it becomes `SystemClock::get()->time()` both variants have 26 characters to type. But IDE autocompletion has to parse 3 parts in `SystemClock::get()->time()` and only 2 parts in `Instant::fromSystemClock()`. If it is not too much trouble I would add them both, because it increases Developer Experience. Kind regards, Mirco Babin
