Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why can't I get a duration in minutes or hours in java.time?

Of the Duration class in the new JSR 310 date API (java.time package) available in Java 8 and later, the javadoc says :

This class models a quantity or amount of time in terms of seconds and nanoseconds. It can be accessed using other duration-based units, such as minutes and hours.In addition, the DAYS unit can be used and is treated as exactly equal to 24 hours, thus ignoring daylight savings effects.

So, why does the following code crash ?

Duration duration = Duration.ofSeconds(3000); System.out.println(duration.get(ChronoUnit.MINUTES)); 

This raises an UnsupportedTemporalTypeException :

java.time.temporal.UnsupportedTemporalTypeException: Unsupported unit: Minutes     at java.time.Duration.get(Duration.java:537) 

So what is the recommended way to extract minutes and hours from a duration object ? Do we have to make the calculation ourselves from the number of seconds ? Why was it implemented that way ?

like image 544
Pierre Henry Avatar asked Jun 30 '14 13:06

Pierre Henry


People also ask

What is the data type for duration in Java?

A Duration represents a directed distance between two points on the time-line. A negative duration is expressed by the negative sign of the seconds part. A duration of -1 nanosecond is stored as -1 seconds plus 999,999,999 nanoseconds.

Can Java duration be negative?

A Duration represents a directed distance between two points on the time-line and can therefore be positive, zero or negative.

How do you subtract time in Java?

String start = "12:00:00"; String end = "02:05:00"; SimpleDateFormat format = new SimpleDateFormat("HH:mm:ss"); Date date1 = format. parse(start); Date date2 = format. parse(end); long difference = date2. getTime() - date1.


1 Answers

"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
like image 80
JodaStephen Avatar answered Dec 02 '22 12:12

JodaStephen