Hi
On 2026-09-22 16:20, Tim Düsterhus wrote:
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
I just had a chat with Derick about the discussion points that have come
up and made some changes to the RFC as a result:
- We added `DateTime(Immutable)::toInstant()` to the proposal as a basic
compatibility layer between the old and new API. `toInstant()` naturally
drops the timezone information, but is otherwise fully lossless, since
Time\Instant is capable of representing better precison (nanoseconds)
than DTI and DT (microseconds). A `DTI::fromInstant()` is missing, since
it's not obvious how to deal with the extended precision. Truncating
might be one choice, rejecting another. The snippet mentioned in
https://news-web.php.net/php.internals/132600 will work and make the
decision (truncation) explicit.
- The behavior of `Instant::toIso8601DateTimeString()` regarding
fractional seconds was adjusted again: Trailing zeros will now be kept
to make the precision supported by Time\Instant explicit.
`2026-09-29T16:42:45.5Z` could mean “exactly 0.5 seconds” or “0.5
seconds ± 0.05 seconds” whereas `2026-09-29T16:42:45.500000000Z` is
explicit as to how precise the data is. This might matter for consumers
that also store an “uncertainty” range.
- The language regarding testing clocks as adjusted as per Seifeddine’s
suggestion: They are not ruled out explicitly and mentioned as possible
future scope. But Derick and I want to be clear in that we don’t plan to
write an RFC for testing clocks, since we remain unconvinced they belong
in core. Personally I also haven't had sufficient exposure to testing
clocks in practice, so I'm not the best person to design the API.
Instead we want to invite you (as the PHP internals community) to write
the follow-up RFC for testing clocks if you'd like to see them in core
and have a good API design ready. Given that the clocks are scoped away
in the dedicated Time\Clock namespace this follow-up RFC also won't need
any coordination with Derick and I and doesn't conflict with our vision
for the new date/time API.
It didn't result in a change to the RFC, but Derick confirmed he agreed
with my reasoning regarding the naming of the ISO-8601 constructor /
getter that I provided in https://news-web.php.net/php.internals/132636.
So I would consider that discussion thread settled.
----------------
Other than that it feels that this RFC has much fewer opinion than
Time\Duration in the same timeframe. Are you all happy and thus didn't
say anything or did you not get around to reading and evaluating the
RFC? If it's the former, feel free to provide a LGTM, ship it. And if
there's anything that bothers you or remains unclear, please mention it,
no matter how big or small.
Best regards
Tim Düsterhus
