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
