Hi Am 2026-06-22 09:01, schrieb [email protected]:
* Go (https://pkg.go.dev/time#Duration) Just int64 of nanoseconds - negative durations are a negative number
A single integer doesn't work for PHP (see my reply to John).
* Java (https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/java/time/Duration.java) Seconds + nanoseconds approachwithout negative flag. Negative durations are represented by a negative number of seconds while nanoseconds are guarantied between >= 0 and < NANOS_PER SECOND
I tested their implementation and consider their representation of negative durations to be unintuitive. Using milliseconds instead of nanoseconds for readability of this example:
A duration of negative 500 milliseconds is effectively represented as (seconds: -1, milliseconds: 500), which can easily be confused with negative 1.5 seconds when “naively” using each component. One needs to calculate `$seconds + 1_000 * $milliseconds` to obtain the correct meaning, which in my opinion is an indicator that the components shouldn't have been split in the first place. Or one always needs to remember that negative seconds are “off by one”.
Or we support negative durations but than it should not be special and following "normal" math. If you need an absolute duration make sure it's positive ... Adding a `abs()` / `absolute()` method (like in Java).
The proposal in the RFC *is* following “normal math”. All the methods correctly take negative values into account. A sign-magnitude representation is also by no means uncommon, IEEE-754 floating points are also using a sign-magnitude representation. Personally I find sign-magnitude to be the leak awkward given the (necessary) second + subsecond split.
Another small note in the naming of `$seconds` and `$nanoseconds` ... The one is the total number, while the other one is the fraction of the unit. If we later on want to add more helper like total number of x and more fraction of different units we have ambiguity naming here. -> I would rename `$seconds` into `$totalSeconds` so maybe later on we can add `$seconds { get => $totalSeconds % 60 }
I haven't yet checked with Derick on this, but given the third paragraph of the “Design Considerations” and Rust’s / Java’s implementation which also use $seconds, I would disagree here. The same issue would also exist when $milliseconds and $microsecond accessors would be added, because $nanoseconds would then need to be restricted to 1_000 using the same argument. In my opinion this kind of “convenience” accessors are better left to explicit and clearly named methods.
Best regards Tim Düsterhus
