Re: In support of Instant.minus(Instant)

I remain happy to see until() go into the JDK. Potentially on more classes than the recent PR. *If* Java gets operator overloading, and *if* it is based on a mapping to method names, then *perhaps* there is a case to consider adding minus(). But I don't feel now is the time. Stephen On Thu, 16

Re: In support of Instant.minus(Instant)

Hi all, Sorry for the delay here. I took a quick look at other popular date/time libraries and there seems to be a fairly strong preference for minus (JS/TS's Temporal library is the only other date/time library that I found which uses until for this concept): - Abseil's Time (C++)

Re: In support of Instant.minus(Instant)

Hi, With Stephen/Roger's comments, as well as Kevin's observation that until(end) has a good argument ordering that is easy to understand, I'd still propose `until()`. Please post if you have further comments. Naoto On 5/3/24 6:39 AM, Roger Riggs wrote: Hi, I would also reinforce

Re: In support of Instant.minus(Instant)

Hi, I would also reinforce Stephen's early observation that the pattern for "until" methods in java.time includes those of the XXXDate classes, with a single Temporal parameter.  Period and Duration are similar values holding relative TemporalAmounts.     public Period until(ChronoLocalDate

Re: In support of Instant.minus(Instant)

Most users don't and won't know anything about "affine spaces" *per se*, however, it's not a super unusual relationship for two types to have. A few examples Point2D and Vector2D Instant and Duration Pitch and Interval (i.e. music theory) If Java has operator overloading one day, I would feel it

Re: In support of Instant.minus(Instant)

`Temporal` interface is clear that its `minus` methods return objects of the same `Temporal` type, and `until` calculates the amount of time until another `Temporal` type. Introducing `Instant.minus` that returns `Duration` would be confusing to me. Naoto On 5/2/24 10:41 AM, Éamonn McManus

Re: In support of Instant.minus(Instant)

I'd say too that this makes intuitive sense based on algebra. If we have: *instant1* + *duration* = *instant2* then we can subtract *duration* from both sides: *instant1 = instant2 - duration* or we can subtract *instant1* from both sides: *duration = instant2 - instant1* There's no manipulation

Re: In support of Instant.minus(Instant)

That doesn't follow for me at all. The structure formed by Instants and Durations is an affine space , with instants the points and durations the vectors. (An affine space is a vector space without a distinguished origin, which of course

Re: In support of Instant.minus(Instant)

On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever wrote: > instant − instant = duration // what we're discussing > instant + duration = instant // satisfied by instant.plus(duration) > instant - duration = instant // satisfied by instant.minus(duration) > duration + duration = duration //

Re: In support of Instant.minus(Instant)

Hi all, Thanks for filing JDK-8331202 (https://bugs.openjdk.org/browse/JDK-8331202). I think this proposal is definitely a step in the right direction. The Instant instance method is much more discoverable than the Duration static method. I also think there's a much lower chance of users

Re: In support of Instant.minus(Instant)

A constructive API enhancement. Created JDK-8331202 Support for duration between Instants Regards, Roger On 4/25/24 4:53 PM, Stephen Colebourne wrote: java.time.* already has the `until(ChronoLocalDate)` method on LocalDate. It would be

Re: In support of Instant.minus(Instant)

java.time.* already has the `until(ChronoLocalDate)` method on LocalDate. It would be reasonable to add a similar method to various other classes. This potentially gives you Duration dur = start.until(end) I'm wary of adding the opposite (given until() is already there). I'm particularly wary

In support of Instant.minus(Instant)

Hi core-libs-dev, The java.time API already supports subtracting two Instants (end - start) via Duration.between(Temporal, Temporal), but we've found the parameter ordering (which requires a bit of "mental gymnastics") and API location to be a bit unnatural. Parameter Ordering We very often see