Re: [RFC] Duration class

From: Date: Mon, 22 Jun 2026 15:20:49 +0000
Subject: Re: [RFC] Duration class
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-131458@lists.php.net to get a copy of this message
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

« previous php.internals (#131458) next »