On Thu, Jun 18, 2026, at 8:47 AM, Tim Düsterhus wrote: > Hi > > Derick and I are proposing the introduction of a new `Time\Duration` > class to represent “stop-watch” or “egg-timer” durations to improve the > developer experience for APIs taking a timeout. We are specifically > targeting PHP 8.6 for this RFC, since part of the motivation is > improving the API of the new “Polling API” that already landed in PHP > 8.6 (https://wiki.php.net/rfc/poll_api) before the “backwards > compatibility” door closes with the feature freeze in two months. > > This RFC is also intended to be a first part of a modernized date and > time API in PHP, while being useful on its own. To that extent and given > the deadline we hope to make, the proposed API is intentionally minimal > and focused on functionality that we are relatively certain to: > > 1. Be correct, or > 2. be requirement for future additions that cannot later be added > without breaking compatibility. > > We would therefore ask to keep the discussion focused on actual issues > rather than additional “convenience functionality” that might require > extensive discussion or thought. > > All that said, you can find the RFC at: > https://wiki.php.net/rfc/duration_class. It hopefully includes all the > important explanation and also provides a rationale as to why we made > the design decisions we made. > > Best regards > Tim Düsterhus
I support this proposal in general. I especially like the public readonly properties. :-) My main suggestions would be for more constructors, though I'm sure that's going to get a response of "MVP, add later." :-P My main pushback, I think, is the fromIso8601String() method, which is not at all self-descriptive. Presuming it means the format accepted by DatePeriod (give or take bugs), that's not self-evident anywhere in the RFC, or the method name. I can easily see people who aren't familiar with that period format (which is, I suspect, most people) trying to use "5:23:44" or similar human time formats instead, which will break. But that format actually feels more useful, and is also defined somewhere in ISO8601 (as part of the full date/time string if nothing else), so the method name is ambiguous. I think we do need to come up with a better, more self-documenting name for that operation, and consider if we also want a fromHumanTimeString() that accepts "5:23"44" type strings. --Larry Garfield
