Hi Tim and Derick, I appreciate the way the Duration class has been introduced. It is intentionally minimal, which is a sensible approach, while still leaving room for future extensions.
However, I would advise against introducing Duration::add and Duration::sub methods. Instead, I would recommend providing a single method, Duration::sum(Duration ...$durations): self. Given that a Duration already carries a sign and may therefore be either positive or negative, the presence of separate add and sub methods could create an implicit and potentially misleading notion of directional behavior. In contrast, a sum method using variadic arguments would allow multiple Duration instances to be combined in a natural and consistent manner. It would also avoid implying any expectation regarding the resulting sign, which may legitimately be either positive or negative depending on the input values. On Thu, Jun 18, 2026 at 11:22 PM Tim Düsterhus <[email protected]> wrote: > Hi > > Am 2026-06-18 22:25, schrieb Frederik Bosch: > > Rather than building a whole new date/time library, did you consider > > using the temporal_rs library instead? This library is used for the new > > Temporal API that is now available in Firefox and Chrome and is > > a browser standard. > > We did not look specifically at temporal_rs (I wasn't aware of its > existing until now), but we looked at JavaScript’s Temporal API - > amongst others. > > I'm not speaking for Derick here, but I do not believe it is possible to > just take an API that was built for a different programming language and > plug it into a different programming language without making any > changes. Different programming languages have different capabilities, > ecosystems and code styles and without adjusting the API to the > respective language, it will just stick out like a sore thumb. > > As an example, JavaScript’s Temporal.Duration.prototype.round is an > overloaded function with one overload taking an “options object”. This > is something that works well with JavaScript’s dynamic nature, but is > something we are moving away from in PHP, because it doesn't interact > well with explicit type-checked signatures that are a first-class > citizen in PHP. Semantically PHP is much closer to Java than it is to > JavaScript and I believe that Java’s `java.time.*` is a comparatively > better fit than JavaScript’s Temporal, but even that cannot be taken > as-is, because Java supports overloaded methods (e.g. > java.time.Duration.minus()) whereas PHP does not. > > The complicated part here is the API design, not the internal > implementation, particularly since PHP already has a date API that > supports all the relevant operations. It's just that the userland API > really starts to show its age. So using temporal_rs under the hood, > while exposing a PHP-specific API will not provide any meaningful > benefit - and would on the contrary add a new dependency on Rust. I'm > not saying that including Rust is a bad idea, but integrating Rust > libraries nicely into the Zend Engine, for example to make them work > with PHP’s `memory_limit` would be a significant undertaking by itself > and not be something we can just do as a “don’t worry about it” > implementation detail. > > Best regards > Tim Düsterhus >
