I am not sure I understand this implementation, but isn’t
> long s = convert(duration.getSeconds(), SECONDS);
needing to actually be
> long s = convert(duration.getSeconds(), NANOSECONDS);
so that s+n is in a common unit of measure?
Gregg
> On May 30, 2018, at 7:19 PM, Martin Buchholz via Concurrency-interest
> <concurrency-inter...@cs.oswego.edu> wrote:
>
> v.0.2 has both conversion methods in TimeUnit. The unexpected weirdness is
> that convert(Duration) saturates while toDuration throws ArithmeticException,
> but both seem author-culture-consistent. Perhaps TimeUnit#toDuration doesn't
> provide enough value in view of the existing Duration.of and
> TimeUnit#toChronoUnit. And most of the time you'd expect to convert from
> Duration to long, just before calling a TimeUnit based method.
>
> /**
> * Converts the given time duration to this unit.
> *
> * @param duration the time duration
> * @return the converted duration in this unit,
> * or {@code Long.MIN_VALUE} if conversion would negatively overflow,
> * or {@code Long.MAX_VALUE} if it would positively overflow.
> * @throws NullPointerException if {@code duration} is null
> */
> public long convert(Duration duration) {
> long s = convert(duration.getSeconds(), SECONDS);
> if (s == Long.MIN_VALUE) return s;
> long n = convert(duration.getNano(), NANOSECONDS);
> assert n >= 0 && n < 1_000_000_000;
> return (s + n < s) ? Long.MAX_VALUE : s + n;
> }
>
> /**
> * Converts the given time duration in this unit to a Duration.
> *
> * @param duration the time duration
> * @return the time duration represented as a Duration
> * @throws ArithmeticException if the duration cannot be represented
> * as a Duration due to numeric overflow
> */
> public Duration toDuration(long duration) {
> return Duration.of(duration, toChronoUnit());
> }
>
> _______________________________________________
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
