LocalDateTime arithmetic: what it means for reliable time handling

TL;DR: Java.time bugs often compile, pass tests, and still return silently wrong answers, especially when LocalDateTime is used across timezones or when tests call now() without an injected Clock, according to Sonar. The risk is not just correctness drift but downstream billing, SLA, and scheduling errors that look plausible enough to survive review.

Editorial analysis by NHI Mgmt Group, based on content published by Sonar: “The java.time bugs that don’t throw exceptions”.

Key questions

Q: What breaks when LocalDateTime is used for elapsed time across timezones?

A: The calculation returns a calendar-style difference instead of true elapsed time, so the result can look plausible while being wrong.

Q: Why do time-based tests become unreliable without an injected Clock?

A: Without a controllable Clock, tests depend on JVM speed, clock resolution, and runtime conditions that vary across machines.

Q: How do teams know when time handling is failing in production code?

A: Look for business logic that depends on elapsed time but uses local wall-clock types, especially where values still appear reasonable in review.

Practitioner guidance

• Use timezone-aware timestamps for elapsed time Replace LocalDateTime duration math with ZonedDateTime or Instant whenever the calculation crosses systems, regions, or user locales.
• Inject a controllable Clock into time-dependent code Refactor code that calls now() so tests can supply a fixed Clock and assert reproducible results.
• Ban identity comparison on value-based time objects Review code for == and identityHashCode usage on Instant, LocalDateTime, Optional, and boxed primitives.

Bottom line: LocalDateTime arithmetic can return believable but incorrect elapsed times when timestamps cross timezone boundaries, which makes the defect easy to miss in review.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →