Durations in existing JDK APIs

[Peter Levart]

Just thinking loud...

On 05/30/18 19:36, Martin Buchholz wrote:
> Obvious progress would seem to be more conversion methods.  Conversion code
> tends to be annoying/errorprone because of having to deal with overflow.
>
> Stephen/Doug: is there any reason we didn't add conversions between
> Duration and TimeUnit when we added conversions to ChronoUnit?
>
> Here's a strawman:
>
>      /**
>       * 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.
>       */
>      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;
>      }

Duration object has a big range (Long.MIN_VALUE ... Long.MAX_VALUE 
seconds) and a nanosecond precision. Both can not always be expressed as 
a pair of (TimeUnit, long) which are the usual parameter(s) of some 
methods. Above API proposal leaves the decision which TimeUnit to choose 
for conversion to the programmer. Would a pair of methods on Duration 
that return a TimeUnit and a long make sense here? The Duration could 
choose TimeUnit so that returned (TimeUnit, long) pair would be as 
precise as possible and still not overflow (like a floating point)...

Peter