Does LocalDateTime across timezones distort elapsed time?

TL;DR: LocalDateTime can produce believable but incorrect elapsed-time calculations when timestamps cross timezone boundaries, according to Sonar. Time-sensitive billing, SLA timers, and scheduling need explicit timezone context or they can pass review while staying wrong.

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

Key questions

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.

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.

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.

Glossary terms: LocalDateTime, Clock Injection, Value-Based Type, Timezone-Aware Arithmetic

Explore further

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