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
