Durations in existing JDK APIs (original) (raw)

Peter Levart peter.levart at gmail.com
Thu May 31 06:06:47 UTC 2018

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.MINVALUE} if conversion would negatively overflow, * or {@code Long.MAXVALUE} if it would positively overflow. */ public long convert(Duration duration) { long s = convert(duration.getSeconds(), SECONDS); if (s == Long.MINVALUE) return s; long n = convert(duration.getNano(), NANOSECONDS); assert n >= 0 && n < 1000000000; return (s + n < s) ? Long.MAXVALUE : 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

More information about the core-libs-dev mailing list