Hi Tim, > On 21.6.2026 15:52 CEST Tim Düsterhus <[email protected]> wrote: > > > Hi > > On 6/20/26 17:50, ignace nyamagana butera wrote: > > Also why are there some restrictions on the factor argument of divideBy and > > multiplyBy to only accept positive integers ? > > At least that is what I understood when I quickly checked the proof of > > concept. Since Duration are signed instances that restriction seems strange > > ? > > Enforcing positive values for multiplication and division means that > flipping the sign of a Duration is a deliberate action and not just > something that happens as part of another operation. > > See also the last paragraph in the “Design considerations” section.
I don't agree on this part of the "Design considerations". The split between seconds and nanoseconds is a reasonable approach but the negative flag is not. Especially that it's not just an implementation detail. This makes the Duration class a very special thing from any other "number of unit" that needs special care on using it. I have looked up the implementations of other Duration classes you mentioned - Go, Java, Rust - none of them have such kind of negative flag. * Go (https://pkg.go.dev/time#Duration) Just int64 of nanoseconds - negative durations are a negative number * 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 * Rust (https://doc.rust-lang.org/src/core/time.rs.html) Seconds + nanoseconds approach without negative flag. Both numbers are unsigned - so no support of negative durations. So either we follow Rust's approach by defining "Negative durations are meaningless" then they should not be supported at all - Means no negative flag and guarantied positive values. 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). Currently it looks like you tried a mix of "negative durations are meaningless" but on the same time you want to support negative durations resulting wired middle ground. To define which way to go I think we need to be clear on what the use cases are and how other use cases will be handled later on. So is that class only for stop-watch & timeouts cases then maybe Rust's approach makes more sense but if we want this class to be used more generically like "diff in seconds of point in time X and Y with direction" a more general duration make more sense. Looking at Java again - The Period class does not support times - just calendar units. 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 } Regards, Marc > > Best regards > Tim Düsterhus
