Duration.toHours returns zero

Question

In the output section below, the "Hours in-between" displayed is zero. The result expected is a non-zero value.

The Java code:

ZonedDateTime zdt1 = ZonedDateTime.now(ZoneId.of("Asia/Calcutta"));
ZonedDateTime zdt2 = ZonedDateTime.now(ZoneId.of("America/Toronto"));
Duration duration2 = Duration.between(zdt1, zdt2);

System.out.format("ZonedDateTime 1 %s\n", zdt1);
System.out.format("ZonedDateTime 2 %s\n", zdt2);
System.out.format("Hours in between %d\n", duration2.toHours());

The output:

ZonedDateTime 1 2021-11-10T16:44:38.237844+05:30[Asia/Calcutta]
ZonedDateTime 2 2021-11-10T06:14:38.239340-05:00[America/Toronto]
Hours in between 0

Michael Berry · Accepted Answer · 2021-11-10T11:54:55.523

5

It's zero because you're literally comparing "now" with "now". The fact that those ZonedDateTime objects are in different zones is irrelevant, since they're timezone aware - they point to the same instant in time.

If you want to compare the number of hours between the local time in each timezone, you can do that by converting them to LocalDateTime objects:

Duration duration2 = Duration.between(zdt1.toLocalDateTime(), zdt2.toLocalDateTime());

...which will give you -10.

edited Nov 10 '21 at 11:54

answered Nov 10 '21 at 11:28

Michael Berry

70,193
21
157
216

Thanks Michael Berry. – We work better Nov 10 '21 at 13:56
One small doubt still remains is that "the content" of the variables zdt1 and zdt2 printed shows two "distinct DateTime" with respect to the Timezone. Therefore is the code really checking "now" with "now". When printing the contents in the format hh:mm:ss, it showed the values "19:40:59" and "9:10:59" wrt to the time zones. And in another point in time it showed "19:53:10" and "9:23:10". One thing noted is that the seconds in each case matched. Will it be always possible. Kindly help to understand it. – We work better Nov 10 '21 at 14:26
1

No, on a normal time-sharing computer you cannot control how much time elapses between the two calls to `now()`, so the seconds need not match. Also while I don’t think any time zone exists that currently has seconds in its UTC offset, Java does support such time zones, so we can’t exclude the existence of one some time, which will again cause the seconds not to match. – Ole V.V. Nov 10 '21 at 23:53

score 0 · Answer 2 · answered Nov 11 '21 at 00:10

A modest supplement to the existing answer.

First, you don’t need to live with an uncertain amount of time elapsing between your two calls to now(). Call now() only once and use the result for both ZonedDateTime objects. Derive one from the other:

    ZonedDateTime zdt1 = ZonedDateTime.now(ZoneId.of("Asia/Calcutta"));
    ZonedDateTime zdt2 = zdt1.withZoneSameInstant(ZoneId.of("America/Toronto"));

    System.out.format("ZonedDateTime 1 %s%n", zdt1);
    System.out.format("ZonedDateTime 2 %s%n", zdt2);

Output right now:

ZonedDateTime 1 2021-11-11T05:31:02.380+05:30[Asia/Calcutta]
ZonedDateTime 2 2021-11-10T19:01:02.380-05:00[America/Toronto]

Not only the seconds, even the milliseconds agree.

It seems that what you are really finding the difference in the current UTC offset between the two times. The existing answer is fine on this point. I am presenting an alternative that I think more directly expresses that we want the difference between the offsets. I am not saying that one solution is overall better than the other.

    int diffSeconds = zdt1.getOffset().getTotalSeconds() - zdt2.getOffset().getTotalSeconds();
    Duration duration2 = Duration.ofSeconds(diffSeconds);

    System.out.format("Amount of time in between %s%n", duration2);
    System.out.format("Hours in between %d%n", duration2.toHours());

Amount of time in between PT10H30M
Hours in between 10

The former line says that the difference is 10 hours 30 minutes. When converting to hours, only the whole hours are included, so 10.

Duration.toHours returns zero

2 Answers2