Hi TIm, On Fri, Jul 3, 2026 at 9:10 PM Tim Düsterhus <[email protected]> wrote: > > Hi > > On 6/29/26 19:42, Tim Düsterhus wrote: > > Thank you for providing that example. The restriction was primarily > > added as a safety: Removing restrictions later is always possible, > > adding them is not. So absent a good use-case choosing the “error” > > option is safer. Given you have provided an example, it makes sense to > > me to lift the restriction. > > > > For the `fromSeconds()` constructor it's not completely obvious how to > > handle negative values there (see the discussion with Marc). I think > > requiring both parameters to have the same sign would be the correct > > solution here, since this will provide for an intuitive representation > > of magnitude (see also below). What do you think? > > > > I'll also discuss this with Derick before adjusting the RFC. > > I have now discussed this with Derick. He said that he would prefer > keeping the restriction for now, particularly since the `fromSeconds()` > constructor is not totally obvious. > > But as mentioned in my previous email, this is something we can revisit > later, for example when adding the “Future Scope” classes, before that > happens, negative Durations are not particularly useful anyways. > > Given the small remaining time until the freeze, I'm going to “close > out” this thread, but it will definitely serve as a useful reference in > the future. Thanks again! I like that new Duration, good new APIs. I was following the discussion and one thing keeps coming to my mind as an API mistake:
public static function fromSeconds(int $seconds, int $nanoseconds = 0) Let me break down my thinking: fromSeconds implies I'm setting a duration in seconds. But there are two arguments — the second is nanoseconds, and milliseconds isn't representable at all. The name promises one unit and the signature quietly provides another. Someone mentioned the Temporal API for JavaScript, which makes Duration construction unambiguous. You mentioned: "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." That's correct, but I don't think it applies here. The fromSeconds issue is a naming defect regardless of language: the method name promises "seconds" and the signature quietly also takes nanoseconds. This isn't a JS-vs-PHP idiom question. PHP already supports named arguments, giving us the same clarity as Temporal object literal without borrowing any JS syntax: Duration::from(seconds: -30, nanoseconds: -500); Duration::from(seconds: -30, nanoseconds: 500); // error Duration::from(seconds: 30, nanoseconds: 500).negate(); A single ::from() with named arguments would be unambiguous, easy to remember, and remove the need for the whole family of from<Unit> statics. If we'd rather keep fromSeconds, fromMinutes, etc., they should each accept only what their name promises, nothing else. This is purely arginfo-driven, so it costs nothing on the implementation side — no C changes required. This is also the last point where the shape of from* can change without a BC break: once released, splitting or consolidating them means a deprecation cycle spanning multiple major versions. btw, also you mentioned Java's time package as the closest thing to DatetimeImmutable etc. I find that package a pain to use for 99% of usages, if not 100%. It is not that I want to say php is not java. However, in the current specific situation, I would totally mention that :) Cheers, -- Pierre @pierrejoye
