On Tue, Sep 22, 2026, at 16:20, Tim Düsterhus wrote: > Hi > > following Time\Duration in PHP 8.6, Derick and I created an RFC for > Time\Instant and Time\Clock as the next part of the new date and time > API: > > https://wiki.php.net/rfc/time_instant_class > > This time we have several months until the next feature freeze, so > there’s place to discuss additional functionality that we missed. > Nevertheless we would like to keep the RFC focused so that every > decision gets the attention it deserves and some bits are already listed > as “Future Scope” to that effect. > > Best regards > Tim Düsterhus >
Hi Tim, I'm just now getting around to reading over the RFC, and I've read most messages but not all of them. So, I apologize if I'm reopening any old discussions here. After spending much of the last 4-5 years working on a database that needs to deal with relativity, I'd recommend dropping the physics framing in the introduction. Time doesn't move at the same speed for everyone, even on Earth, and you don't specify a frame of reference for the instant. It would also make it easier to explain `until` as "computes the difference between two represented time values. It does not establish how much physical time elapsed between the events that produced those values." This also raises a question about uncertainty. I appreciate that the RFC distinguishes the nanosecond precision of the representation from the resolution of the underlying clock. However, `Clock::now()` returns only an `Instant`, with no way through that contract to convey the source resolution or any available uncertainty information. I've had servers lose access to their hardware clock due to hardware malfunctions, so this is not just a theoretical concern. Where that information is available, it should be preserved alongside the reading. Where it is unknown, it should remain explicitly unknown. Printing nine fractional digits cannot supply that information. That being said, other than the introduction throwing me into a "things programmers wrongly believe about time" rage, this is really well written. I think there are some things worth addressing in the current RFC: 1. `Instant` should throw when serialized to JSON. I understand the argument is that applications should choose their own representation, but the choice should be enforced rather than silently doing the wrong thing. Or provide an opaque serialization that can restore the `Instant`. 2. `DateTimeInterface` is missing the `toInstant()` method, is that by design? 3. The backward-compatibility section still says this RFC only introduces three new namespaced symbols. It should also cover the new methods on `DateTime` and `DateTimeImmutable`, including potential conflicts with existing subclass methods named `toInstant()`. — Rob
