Hi Am 2026-06-22 17:00, schrieb Larry Garfield:
I know we used RFC names in the Uri component, but in that case there's two competing specifications that we're trying to support so using those technical names in namespaces made sense. However, that's not generally true; including random spec IDs in method names is not helpful, and as far as I am aware there's only one type of "time period string" on the market that we need to worry about so there is no risk of the same type of confusion. (If there are others, please let me know.)
Golang’s `time.ParseDuration()` accepts stuff like `"1µs"`: https://pkg.go.dev/time#ParseDuration. The `sleep` binary from GNU coreutils also accepts a (single) suffix. You can find the man page here: https://manpages.debian.org/testing/coreutils/sleep.1.en.html
I would expect this kind of “informal format” to be much more common in use than an ISO-8601 period string, which will lead to users trying to do `Duration::fromPeriodString('5s')`. And then of course for those there is the ambiguity between “minute” and “month” with `Duration` only being able to support “minute”, but perhaps folks might want to try `5min` instead to disambiguate.
The `Iso8601` in the proposed method name *is* meaningful and important to steer users towards the correct specification.
Especially as it is supported in other parts of the current date/time API.
… and these “free-form human language” inputs are a common source of confusion in the current ext/date API. In any case, that's definitely not something for PHP 8.6.
Best regards Tim Düsterhus
