"Why was it implemented that way?"
Other answers deal with the toXxx()
methods that allow the hours/minutes to be queried. I'll try to deal with the why.
The TemporalAmount
interface and get(TemporalUnit)
method was added fairly late in the process. I personally was not entirely convinced that we had enough evidence of the right way to work the design in that area, but was slightly arm-twisted to add TemporalAmount
. I believe that in doing so we slightly confused the API.
In hindsight, I believe that TemporalAmount
contains the right methods, but I believe that get(TemporalUnit)
should have had a different method name. The reason is that get(TemporalUnit)
is essentially a framework-level method - it is not designed for day-today use. Unfortunately the method name get
does not imply this, resulting in bugs like calling get(ChronoUnit.MINUTES)
on Duration
.
So, the way to think of get(TemporalUnit)
is to imagine a low-level framework viewing the amount as a Map<TemporalUnit, Long>
where Duration
is a Map
of size two with keys of SECONDS
and NANOS
.
In the same, way, Period
is viewed from the low-level frameworks as a Map
of size three - DAYS
, MONTHS
and YEARS
(which fortunately has less chance of errors).
Overall, the best advice for application code is to ignore the method get(TemporalUnit)
. Use getSeconds()
, getNano()
, toHours()
and toMinutes()
instead.
Finally, one way to get "hh:mm:ss" from a Duration
is to do:
LocalTime.MIDNIGHT.plus(duration).format(DateTimeFormatter.ofPattern("HH:mm:ss"))
Not pretty at all, but it does work for durations less than one day.
New to…Part
methods in Java 9
JDK-8142936 issue now implemented in Java 9, adding the following methods to access each part of a Duration
.
toDaysPart
toHoursPart
toMinutesPart
toSecondsPart
toMillisPart
toNanosPart
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…